Applying SABSA to Agent Behavior

An Authorized Actor With a New Failure Mode

An agent workforce stresses that access-centric implementation layer in a way it wasn't built for.

An agent is not outside the boundary. It is an authorized actor with access to whatever sensitive tools and data its job requires: authenticated, authorized, and granted what it needs to do real work. Depending on what it's authorized to touch, it can be turned against you while satisfying every configured endpoint permission, because the attack does not have to breach a control at all. It can ride in on the very input the agent exists to process.

Security researcher Simon Willison named the risky combination the lethal trifecta: give an agent access to sensitive data, expose it to untrusted content, and let it communicate outward, and you have built an actor that can be instructed by a stranger. Willison's own guidance is not that all three are unavoidable job requirements — he recommends avoiding the combination where possible. An agent scoped to internal data with no outbound channel, or one with no access to untrusted content, can still do useful work; it's the co-occurrence of all three that creates the exposure, not any single capability on its own.

Authentication, Authorization, and the Gap Between Them

Authentication establishes who the agent is. Authorization determines what it may do under applicable conditions. Neither tells you what the agent can be talked into doing with the authority it already holds.

SABSA can model an insider threat and grade trust domain by domain, and its business-attributes and risk layers are built to reason about exactly this kind of question. The practical gap is in how access-centric implementations of it typically get built: as a set of controls decided once, at grant time, rather than controls that re-evaluate as an agent's context and action sequence change mid-task. An agent can be authorized correctly for exactly what its job needs, and still be manipulated, through the very input it exists to process, into using that authorization in a way the grant never anticipated. SABSA can accommodate this risk in its own terms; the implementation challenge is translating business intent into controls that constrain an agent's use of legitimate permissions as its context and action sequence change, not building a new framework from nothing.

Tightening Access Helps, But Doesn't Finish the Job

The instinct is to clamp down on access, and that instinct isn't wrong — task-specific permissions, recipient restrictions, and removing capabilities an agent doesn't need for a given job can materially reduce exposure. What tightened access alone doesn't resolve is the case of a fully authenticated, fully authorized agent doing something within its permissions that its context, at that moment, should not have allowed. That residual case lives one layer below static access, in behavior: what an authorized actor is induced to do with authority it legitimately holds, in a specific context. SABSA's access-centric implementations don't have a native answer for that layer by default.

Enforcement Moves to the Moment of Behavior

So security architecture has to add a layer access-centric implementations typically didn't need before agents. The question moves from "is this actor allowed in" to "is this action, on this input, right now, inside the bounds of what this worker should be doing at all." Enforcement shifts from the moment of authentication to the moment of behavior.

This is already taking shape, not theory. For example, an AI gateway can sit in the inference path between the agent and the models it calls, and inspect, constrain, or record what the agent is about to do rather than only whether it was allowed to connect. Coverage is not automatic: a gateway on the inference path does not by itself mediate every subsequent tool-execution call an agent makes, and how much of an agent's behavior is actually governed depends on which action paths are wired through enforceable controls versus which bypass the gateway entirely. Where that coverage is real, though, it is a control layer access-centric security architecture typically did not build for, because it was not designed around an actor whose next action depends on its last input.

The Badge Is Already Issued

SABSA's own model can reason about an actor holding a badge it was legitimately issued. What still needs building, in most access-centric implementations of it, is the layer that asks not who gets in, but what a badge-holder can be persuaded to do once inside.

The Bridge to Capability Governance

About This Series

Cite the Position Paper

@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}