Treat Agents Like Direct Reports

Companies deploying AI agents should give each agent its own principal identity, short-lived tokens, and a chain of custody attributing its actions to a named creator, rather than sharing one API key across hundreds of .env files, according to a Cloudflare-authored post on agent identity. The post recommends routing every agent and app through a gateway that holds secrets, and promoting agent-built apps from personal to team to org level so an app gets its own keys and survives its creator's departure. It cites Cloudflare OS as one of the few projects with thought-out primitives for letting an agent reach a system without the key landing in its context window.

01 / The slop cannonGive every agent a name badge Over the last couple of months I’ve met with a lot of companies at various stages of AI adoption, and the spread is huge. At one end are companies that have installed Microsoft Copilot in their corporate systems and are dipping their toes in. At the other end are the AI-native companies: nobody reads the code, every person has massive token budgets, agents are shared, there’s a company brain, and everything runs in loops. In the middle is a group I find fascinating. They’ve embraced AI, built a company brain, and let employees spend thousands on tokens every month. What they’ve done is hand every employee a slop cannon. Everyone is building. Effort gets duplicated, apps multiply, and IT doesn’t know what to do with any of them. It’s worst at companies that never fully set up identity or permissions. That’s where you get API key sprawl. There’s also no default pattern for a gateway, meaning a way for an agent to reach a system without the key ever landing in its context window. Cloudflare OS https://os.cloudflare.app/ is one of the few projects with thought-out primitives around that. Nobody has a standard for doing this well yet. 02 / One opinionEach agent is its own principal Meeting these companies has left me with one firm opinion. Give each agent its own principal identity in your system. Treat agents like direct reports to the person using their agent. That means two things. An agent never gets more access than the person using it, and it usually gets less. And it gets its own principal identity: it isn’t Alice, it works for Alice. When you’re starting out, pick generous defaults so you don’t cripple their agents and turn users away. Later, as people get better at this, you can teach them to scope permissions down: “make an agent that can only read the finance database and build me a dashboard,” instead of pointing an agent that can touch everything at the problem. The worst case is one API key shared across a company, copied into hundreds of .env files and used by everyone and all their agents. Fix that first. It’s a recipe for disaster. If you do nothing else - Each agent has its own identity. - It gets short-lived tokens. - Its actions are attributed to it. - There’s a chain of custody: Alice created this agent. 03 / PromotionWhen the agent ships an app The next level is when an agent produces something that runs, and other people in the company start using it. Now you have an owner, Alice, and a viewer, Bob. The common default is that the app runs with Alice’s permissions, whoever is using it. Sometimes it’s an app anybody can edit. Both bring back the key-sprawl problem. The answer is promotion. Plenty of apps should stay Alice’s: they run with her permissions, and only she can see and edit them. Once her whole team wants to use one, promote it to the team level and add maintainers who can see the source. Past that, promote it to the org level. Bigger companies will have more levels in between. Alice is still the creator, but the app becomes an app in the organization like any other. It leaves the agent’s identity behind, gets a principal of its own, and reads and writes data with its own keys. Two things fall out of this. First, seeing an app and having its access are separate. Say Alice’s agent builds a sales dashboard with read access to the CRM, and Alice shares it with the sales team. Bob can now see the dashboard, but he doesn’t get CRM access. Second, the app survives its creator. If Alice leaves, the grants that came from her stop working and the dashboard stops refreshing, but it doesn’t disappear. The sales team adopts it, grants it CRM access of its own, and it starts refreshing again with the same URL. 04 / ArchitecturePut a gateway in the middle Route every agent and app through a gateway, and keep the secrets there. Each identity gets its own key pair, or a key baked into the hardware or virtual hardware it runs on. When a call arrives, the gateway looks up who is making it and checks that against the identity’s grants. This sounds complicated. It doesn’t have to be. Here’s what it looks like: - The sandbox has no network. Agent code runs in a sandbox with no outbound network access. Every external call is a request to the gateway. - Keys are added at the gateway, and only there. The gateway keeps an allowlist of approved services and attaches the right credential to each outgoing call. The agent’s code can’t choose which secret gets used, and the gateway removes the value from anything it sends back. The agent never sees a key. - Every sandbox carries a short-lived signed token. It names the organization, the agent, and the chat or resource it’s working on. - Grants are a ledger. Each grant records who gave it, who received it, the permission, the parent grant, an expiry, and whether it was revoked. You can only pass on a permission you already hold, so delegation can narrow access but never widen it. Revoke a parent grant and everything delegated from it stops working. Every grant and revocation is logged as an event, and the log is never rewritten, so there’s always an answer to “why can this app do that?” That core is small. Astra can write it in about 15 minutes. I know because I had it do it.