By Robin Martherus
I keep getting the same question: “Will security policies for AI agents be much different from policies for humans? Do we need to distinguish a human connected to the network from an agent?”
The question assumes the current policy model is right for humans and we just need to decide whether to extend it or create a new one for agents. That assumption is wrong. The current model — individual policies defining which identity has access to which resource — was already failing before agents arrived. Agents are just the forcing function that makes the failure impossible to ignore.
How Policies Work Today
The current enterprise security model is identity-centric. You define policies per identity:
- Robin in the Engineering group can access the source code repository
- Maria in Finance can access the accounting system
- The CI/CD service account can deploy to production
This model answers one question: “Can this identity access this resource?” It answers it with roles (RBAC), attributes (ABAC), or scopes (OAuth). The identity is the key. The policy is the lock. You match keys to locks and call it security.
To be fair, the industry has iterated. ABAC was a significant improvement over RBAC — moving from static role assignments to dynamic attribute evaluation. When an employee changes managers, the attribute changes and the policy adjusts. When someone gives notice, the employment-status attribute updates and permissions narrow. ABAC brought real dynamism to access control and its ability to revoke or adjust permissions based on changing attributes was a genuine architectural advance.
But even ABAC still answers the same fundamental question: “Can this identity, with these attributes, access this resource?” The attributes are richer than roles. The evaluation is more dynamic. But the policy unit is still the identity, the model is still about access, and the question is still “can” — not “why” or “should.”
This worked when identities were stable and predictable. Robin in Engineering reads code, writes code, reviews code. The role (or attribute set) describes what Robin does. The policy matches.
What follows is an argument that this model needs to evolve — not that your identity infrastructure should be thrown away. Identity remains critical. What changes is its role: from being the policy itself to being the anchor for a richer governance model above it. The infrastructure stays. The policy model evolves.
Why It Was Already Failing
Long before agents arrived, the identity-centric model was showing cracks:
Permissions accumulate and never shrink. An employee changes departments. Their old permissions stay. A project ends. The service account lingers. Research across 550 million records found 16% of business-critical data is overshared, with 802,000 files at risk per organization. The identity-based model grants access at one point in time. Nobody reviews it when context changes.
Identity tells you nothing about purpose. Robin has access to the source code repository. Is Robin reading code to fix a bug, or downloading the entire codebase before joining a competitor? The identity is the same. The permissions are the same. The purpose is completely different. Identity-based policies cannot distinguish between these cases because identity does not carry purpose.
Context is invisible to the policy. The company enters a SOX audit freeze. A litigation hold is placed on financial records. An employee submits their resignation. The policy engine knows none of this. It checks the role, checks the resource, says yes — because nothing in the identity-based model connects organizational context to access decisions.
These are not agent problems. These are policy model problems that have existed for the entire lifetime of identity-based access control. We managed them with compensating controls — access reviews, DLP, insider risk programs, UEBA — bolted on after the fact because the core model couldn’t handle them.
The Industry’s Response: Add Agents to the Directory
The industry’s current answer to “how do we govern agents?” is to extend the identity-based model: enumerate known agents, assign them non-human identities (NHIs), register them in expanded identity management products, and apply the same role-based policies.
At RSAC 2026, every major identity vendor shipped this: Microsoft Entra Agent ID gives agents identity objects alongside users. Cisco Duo registers agents and maps them to human sponsors. Okta discovers and catalogs AI agents. CyberArk manages agent credentials through privileged access controls. Astrix fingerprints and discovers shadow agents.
This is a necessary and useful step. It gets something out the door quickly. It addresses the immediate problem that enterprises cannot see which agents are operating in their environment. And it gives vendors a credible “we handle AI agents now” story.
But it is the same architectural move the industry made with every previous security challenge: extend the current model to cover the new actor. ACLs were extended with better ACL management tools before identity management replaced them. Perimeter firewalls were extended with DMZs and VPN concentrators before Zero Trust replaced the perimeter model. And now identity management is being extended with NHI registries and agent discovery tools before — what?
The extension works as a temporary bandaid. It does not solve the structural problems because the problems are in the model, not in the coverage:
- Registering an agent in Microsoft Entra tells you the agent exists. It does not tell you what the agent is doing right now, whether its current action is appropriate given organizational context, or whether it has earned enough trust through demonstrated behavior to act autonomously.
- Assigning an NHI to an agent gives it a credential. It does not give it a purpose declaration, a behavioral trajectory, or a normative evaluation before each action.
- Mapping an agent to a human sponsor creates an accountability chain. It does not attenuate scope at each delegation hop, decay trust without reinforcement, or evaluate proportionality of actions.
The NHI approach answers “can we see this agent?” and “does it have credentials?” Those are the right first questions. They are not the last questions. And extending the identity-per-policy model to cover agents at scale will produce the same policy sprawl, the same permission accumulation, and the same context-blindness that the model already produces for humans — just faster and at larger scale.
Agents Make the Structural Failure Impossible to Ignore
Agents didn’t create the problem. They amplified it to the point where the compensating controls can’t keep up.
Scale breaks identity-per-policy. You can write policies for 10,000 employees. You cannot write individual policies for 1.3 billion agents (IDC’s 2028 projection). Agents spawn sub-agents. Sub-agents delegate to other sub-agents. 93% use unscoped API keys with no cascade revocation. Writing a policy per identity was already tedious at human scale. At agent scale, it is architecturally impossible.
Agents shift roles in real time. RBAC assumes stable roles. An agent may read data, analyze it, generate a report, email the report, and update a dashboard — shifting between reader, analyst, writer, and sender within a single task. No role covers this. No policy anticipated it.
Agents can’t be distinguished from humans reliably. At the frontier, behavioral detection approaches chance accuracy. If you can’t reliably tell whether the actor is human or agent, you can’t select which policy model to apply based on what the actor is. The policy model must work regardless.
Agents delegate without narrowing. When a human asks a colleague for help, there is an implicit scope — the colleague uses judgment about what to share and what to withhold. When Agent A delegates to Agent B, the credentials forward at full strength. The “judgment” that a human collaborator would apply does not exist in the delegation chain.
The Wrong Question
“Do agents need different policies than humans?” is the wrong question. It assumes the policy unit is the identity — define policies for humans, then decide whether agents get the same policies or different ones.
The right question is: “Should the policy evaluate the actor or the action?”
If you evaluate the actor, you need to know what it is (human or agent), maintain policies per identity, and keep those policies current as roles change, people leave, and agents spawn. This is what we do today. It is failing for humans. It will fail catastrophically for agents.
If you evaluate the action, you don’t need to know what the actor is for the governance decision. You need to know: what action is being taken, on what target, in what context, with how much earned trust, for what declared purpose. The governance decision is the same regardless of whether the actor is Robin, Robin’s AI assistant, or an autonomous agent Robin has never interacted with. You still need identity — to anchor the trust score, to authenticate the actor, to provide accountability. But identity becomes an input to the governance model, not the governance model itself.
What Action-Based Governance Looks Like
Instead of: “Robin in Engineering can access the source code repository”
The governance model evaluates: “This actor wants to access this resource. Has the actor earned enough trust? Is the declared purpose appropriate? Given the current organizational context — is it audit freeze week? Is this data under litigation hold? Is the actor in their notice period? — should this action proceed?”
The same evaluation applies whether the actor is Robin, Robin’s copilot, a CI/CD pipeline, or a vendor’s monitoring agent. The policy doesn’t care what the actor is. It cares what the actor is doing, in what context, with how much earned trust.
Concrete examples:
| Scenario | Identity-Based Policy | Action-Based Policy |
|---|---|---|
| Departing employee accesses trade secrets | Allowed — role hasn’t been revoked yet (HR ticket pending) | Escalated — actor is in notice period + target is trade-secret classified + action is export. Context triggers review regardless of identity. |
| Agent exports financial data during audit | Allowed — service account has export permissions | Denied — temporal context is SOX audit freeze + action is financial export. Same denial whether a human or agent initiated it. |
| New agent with no history requests sensitive data | Allowed — OAuth token has the right scopes | Restricted — actor trust is minimal (new, no behavioral trajectory). Must declare purpose. Low-risk read access only. Full access earned through demonstrated consistency. |
| Copilot summarizes confidential emails | Allowed — user has access to their own email | Denied — target emails carry sensitivity labels that indicate special handling required. The action (summarize for display) conflicts with the data’s handling requirements regardless of who asks. |
| Security agent scans external system | Allowed — security team service account has scan permissions | Denied — target is external (not first-party) + no written authorization on file. Ethical boundary: scanning external systems without authorization is prohibited regardless of the actor’s role. |
In every case, the identity-based policy says “yes” because the credentials are valid and the role has the permissions. The action-based policy evaluates context that the identity-based model cannot see.
Trust Replaces Role — and It’s Simpler
Here is something the industry has not yet recognized: trust-based governance is not just better than identity-based policies. It is dramatically simpler.
A typical enterprise RBAC deployment has hundreds of roles and thousands of policy rules mapping identities to resources. An ABAC deployment has fewer roles but more attributes, more conditions, and more complex policy logic. Every new resource, every new role, every organizational change spawns more rules. The policy set grows monotonically. Nobody prunes it because nobody knows which rules are still needed. The result is thousands of rules that no human fully understands, administered by a team whose primary job is managing the complexity the model itself creates.
Trust-based governance reduces this to three core policies:
- Trust above threshold X → allow. The actor has earned enough trust through demonstrated behavioral consistency. The action proceeds. No human review needed.
- Trust between X and Y → escalate. The actor has some trust but not enough for autonomous action at this risk level. A human reviews and approves or denies.
- Trust below Y → deny. The actor has insufficient trust. The action is blocked.
That is the entire access decision for 90%+ of actions. Three rules instead of thousands.
The thresholds X and Y are calibrated per action risk class — a low-risk read operation might allow at trust 30 and deny below 10, while a destructive production operation might require trust 80 and deny below 60. But the policy structure is the same three rules applied to every action. The complexity moves from the number of rules to the computation of trust — which is handled by the trust physics engine, not by human policy administrators.
RBAC and ABAC rules do not disappear. They become exceptions to the trust model — overrides for specific situations that the trust computation alone cannot handle. A SOX audit freeze is a normative constraint that denies financial actions regardless of trust level. A departing employee’s trade-secret access is a Soul veto (binary deny) regardless of how much trust they’ve earned. These are exceptions, not the primary model. In a well-tuned deployment, the exception set should be small — tens of normative constraints, not thousands of RBAC rules.
Combined with the other layers — declared purpose constraining what actions are in scope, normative constraints evaluating organizational context, and the trust computation determining how much latitude the actor has earned — the governance model handles the same decisions that today require thousands of identity-resource policy mappings. It handles them with less administrative overhead, less policy debt, and more contextual intelligence.
Identity Still Matters — But Not for Who You Are
This does not mean identity goes away. Identity is critical. But its purpose changes.
In the current model, identity answers: “Who is this person?” Robin Martherus, Engineering, employee #4523. The identity carries a name, an email, a department, a role. The policy engine looks up Robin’s permissions based on who Robin is.
In the trust-based model, identity answers: “Which trust trajectory does this action belong to?” The identity is an anchor — a persistent, cryptographically secured identifier that binds a behavioral history to a consistent principal. It does not need to carry a name. It does not need to carry an email address. It needs to carry a key that resolves to a trust score, a behavioral trajectory, and a delegation chain.
Think of it this way: the identity is the account number, not the account holder’s name. The bank doesn’t need to know your name to evaluate whether a transaction from account #7291 is consistent with that account’s history, within that account’s trust level, and appropriate given the current context. It needs to know the account number is real, that the transaction is cryptographically signed by the account holder, and that the trust model says this transaction is within bounds.
In practice, this means the identity layer evolves toward:
- Cryptographic identifiers — DIDs, hardware-attested keys, or similar — that prove “this is the same actor as last time” without revealing who the actor is
- Trust tokens — short-lived, signed attestations carrying the current trust level, trust tier, and purpose hash — not names, roles, or organizational attributes
- Selective disclosure — the actor reveals identity attributes only when the governance decision requires them (a Tier 3 ethical constraint involving a minor may require the actor’s human sponsor to be identified; a routine Tier 1 compliance check does not)
The identity anchors the trust. The trust governs the action. The identity does not need to answer “who is this?” to do its job. It needs to answer “is this the same principal whose behavioral trajectory earned this trust level?” That is a cryptographic question, not a directory lookup.
The “Who” Still Has Tremendous Value
To be clear: the identity that answers “who is this person?” does not disappear. It remains essential for accountability. When an agent causes harm, you need to trace back to the human who sponsored it, authorized it, or directed it. When a trust identity is involved in a regulatory investigation, you need to resolve it to a person. Accountability requires “who.”
But the “who” identity and the trust identity can be separate layers. The trust identity — the cryptographic anchor that carries the behavioral trajectory and trust score — is what the governance engine evaluates in real time. The “who” identity — the binding to a specific human — sits behind it, resolvable when accountability demands it but not required for every governance decision.
This separation enables something powerful: one human, multiple trust identities. Robin at work and Robin as a consumer at home are the same person but operate in completely different trust contexts. Robin’s work trust identity has a six-month trajectory of consistent behavior within the engineering environment, earned trust in the corporate trust zone, and a declared purpose tied to engineering tasks. Robin’s consumer trust identity has a separate trajectory — different services, different behavioral patterns, different trust earned in a different context.
The same is true for agents. An agent operating in the production environment earns trust in that context. The same agent code deployed in a staging environment earns trust separately. An agent operating within Organization A’s trust zone has a different trust trajectory than the same agent operating in Organization B’s zone — because trust is contextual, not universal.
The “who” ties them together for accountability. The trust identities operate independently for governance. You can answer “Robin is responsible for both of these trust identities” without requiring the governance engine to know Robin’s name every time it evaluates an action.
Authentication Is How You Claim Your Trust
If identity anchors the trust and “who” provides accountability, authentication is the mechanism that ties them together in the moment: it proves you are the one who earned this trust.
Without authentication, anyone could claim your trust identity and act with your earned trust score. A trust model without authentication is like a bank account without a PIN — the balance exists, but anyone who knows the account number can spend it.
This is where the evolution of authentication protocols matters. Traditional bearer tokens (OAuth access tokens, JWTs) can be stolen and replayed — whoever holds the token is the identity, and inherits whatever trust the identity has earned. Newer protocols like AAuth (Dick Hardt’s Agent Auth) use proof-of-possession — HTTP Message Signatures on every request, where the private key never leaves the holder. The token alone is useless without the cryptographic key that proves you are the actor whose behavioral history earned this trust level.
Authentication does not determine what you can do — that is the trust model’s job. Authentication does not evaluate whether you should do it — that is the normative layer’s job. Authentication proves one thing: you are the principal who earned this trust. It is the claim mechanism for the trust identity. Without it, the entire model collapses — because trust that can be stolen is not trust at all.
This vision aligns with where decentralized identity (W3C DIDs, Verifiable Credentials) is heading — and agents may be the use case that finally makes it practical. Agents can manage cryptographic keys natively. They operate across organizational boundaries where no single directory has the full picture. The identity is the anchor. The trust is the governance. The “who” is the accountability layer that connects them to a human when it matters.
Does It Matter if It’s a Human or an Agent?
For governance decisions: no. For some operational details: yes, but less than you think.
- Agents can declare intent explicitly — structured, machine-readable purpose statements. Humans cannot (they browse, explore, change their mind). This means agents can be governed more precisely, not less. The agent declares “generate quarterly report from CRM data” and is held to that contract. The human just opens the CRM and browses. The agent’s governance is actually tighter than the human’s.
- Agents operate at machine speed — the governance engine must evaluate in milliseconds, not the seconds or minutes a human workflow allows. This is an engineering constraint, not a policy difference.
- Agents delegate to other agents — creating chains that need scope attenuation at each hop. Humans delegate too, but informally and with implicit judgment. Agent delegation needs the same judgment encoded structurally.
But the policy model — evaluate the action, not the actor — is the same for both.
The Real Evolution
The policy evolution is not from “human policies” to “agent policies.” It is from identity-based policies to action-based governance — for everyone.
| Current Model | Evolved Model | |
|---|---|---|
| Policy unit | Identity (who has access to what) | Action (should this happen in this context) |
| Trust model | Binary (authenticated or not) | Continuous (earned through behavior, decays without reinforcement) |
| Purpose | Not captured | Declared and enforced as behavioral contract |
| Context | Invisible to the policy | Central to every evaluation (timing, regulatory state, target sensitivity) |
| Human vs. agent | Different policy sets needed | Same governance model, same evaluation, same trust mechanics |
| Scale | Policy per identity (breaks at agent scale) | Constraint per context (scales to any number of actors) |
Agents are the catalyst, not the destination. The destination is a governance model where every action — by any actor — is evaluated against earned trust, declared purpose, and organizational context. That model is better for agents AND better for humans.
That is the architecture behind Tamed Autonomy — and it is the architecture the industry needs to build together, the same way SAML required cooperation to define federation and OAuth required cooperation to define authorization. Not a product. A set of primitives — intent declarations, computed trust, normative constraints — that work for every actor, because the governance evaluates the action, not the identity.
Sources
- 16% of Business-Critical Data Overshared — Gartner via Winbuzzer
- 93% of Agent Projects Use Unscoped API Keys — Grantex
- Dual Turing Test: Detection Approaches Chance Accuracy — arXiv
- Copilot Ignoring Sensitivity Labels — VentureBeat
- ABAC Definition (SP 800-162) — NIST
- Kinetic Trust Protocol RFC — NMCITRA
Leave a Reply