Three Layers of Agent Permission Scoping

Your agent needs to read a database, post to Slack, and call an external API. What permissions does it get? Most teams answer: all of them. Or none. And that’s the problem.

The answer: Agent permissions aren’t binary. They work in three layers. Identity tells you who the agent is. Scope tells you what it can reach. Context tells you whether it should reach it right now. Stack them together and you stop guessing. This three-layer approach aligns with NIST SP 800-207 zero trust principles, which demand verification at every step, and matches OWASP guidance on LLM application security on agent security architectures.

Layer 1: Who is this agent?

Every agent needs a unique, auditable identity. Not a shared service account. Not “admin” credentials buried in .env. A specific credential tied to a specific agent, with a specific owner, that you can trace in logs. Identity providers like CyberArk and Okta have published frameworks for exactly this kind of machine identity layering.

Think about a doctor in a hospital. That doctor doesn’t get a staff badge labeled “Employee.” They get a credential with their name, their ID number, their department, and their hire date. When they access a patient record, the hospital logs not “someone accessed this” but “Dr. Chen accessed this at 2:34pm.” The hospital can find her. The hospital can revoke her access. The hospital knows exactly who pulled what data.

Your agents need the same structure.

If you deploy an agent without a unique identity, you’ve already lost visibility. You can’t audit it. You can’t revoke its access without breaking everything else. You can’t tell whether it’s the agent doing something weird or someone else impersonating it. Don’t do this.

Start simple: each agent gets a UUID and a human-readable name. Each agent credential is pinned to that identity. Each action the agent takes is logged with that identity. That’s Layer 1.

Layer 2: What can this agent actually reach?

Once you know who the agent is, define what it’s allowed to touch. Explicitly. In writing.

This is where most teams get sloppy. They hand an agent the database URL and say “go read the user table.” The agent can read the user table. It can also read the password-reset tokens table. It can read the admin notes. It can read deleted accounts. None of that was intentional.

Scope means you say: “This agent can read these three columns from this table. It cannot write anything. It cannot call the payments API. It can post to #engineering-alerts and #incident-response but not #leadership.” You define it up front. The agent checks its scope before each action.

A doctor’s scope is similar. They can access medical records for their patients. They can’t look up their neighbor’s test results just because they work at the same hospital. They can’t prescribe outside their specialty. The hospital’s access control system enforces their scope every time they touch a record.

Your agent’s scope should be just as specific.

This gets harder when agents start chaining actions. An agent that reads a database and posts to Slack needs read access to the database and write access to Slack. But maybe it only needs to post to one channel. Maybe it only needs to read tables created after a certain date. The specifics vary. The principle doesn’t: define the boundaries before you need them.

Layer 3: Should it access this right now?

The first two layers answer static questions: who is this, and what’s on the menu. Layer 3 answers a dynamic question: is this action reasonable given what’s happening right now?

Time-of-day restrictions. Request-volume limits. Anomaly detection that flags unusual patterns. If an agent that normally reads 100 rows suddenly tries to read 100,000, that’s not necessarily an attack. But it’s worth pausing and checking.

In the hospital: A doctor can see records for her patients. But if she suddenly tries to print records for everyone in the system, someone notices. If she logs in at 3am requesting access from an IP address in another country, alarms go off. The hospital doesn’t just check “does this person have credentials and are they in the building.” It checks “is this credential being used in a way that makes sense.”

For agents, this layer catches three things: misconfigurations that made it through Layers 1 and 2, genuine attacks or compromised credentials, and bugs in the agent itself. An agent that enters an infinite loop and hammers your API will trigger rate limits. An agent that gets confused and tries to delete data when it should only read will hit access boundaries. Context-aware limits give you a second chance to catch mistakes before they become incidents.

What does the gap look like?

Most production agents today skip at least two layers. You might have a unique identity (Layer 1), but shared credentials for scope (Layer 2), and no runtime checks at all (Layer 3). Or you’ve got scope defined in documentation that nobody reads and no way to enforce it. Or you’ve got everything hardcoded and the first time you need to change permissions, you redeploy everything.

Pick one agent in production right now. The one that’s most critical, or the one you worry about most. Write down:

• Who owns this agent? (Layer 1: identity)
• What databases, APIs, and services can it touch? (Layer 2: scope)
• What limits are actually running? Rate limits? Time windows? Anomaly detection? (Layer 3: context)

Compare what you wrote to what’s actually deployed. That gap is your action item.

If the gap is large, start with identity. Get each agent a unique credential. Once that’s in place and you can see what your agents are actually doing, add scope. Then add context.

You don’t have to solve all three layers at once. But you do have to solve them.

Once you’ve mapped the three layers, the next step is measuring whether they’re actually working. Friday’s checklist walks you through nine concrete checks you can run in 90 minutes to find permission drift before it costs you.