Skip to content
EAA Series · Part 2

When AI Becomes a Workforce, SABSA’s Risk Model Inverts

SABSA controls the door. The agent already has a badge. The question is no longer who gets in, but what a trusted worker can be persuaded to do once inside.

Read

SABSA earned its place by making security traceable. Every control links back to a business risk; every layer, from contextual to operational, answers to the one above it. It is a rigorous, business-driven way to decide who may hold what access, at what trust level, under whose authority — and to prove every control traces back to a risk worth spending on.

The Most Privileged Insider

An agent workforce turns that model inside out.

The agent is not outside the boundary. It is your most privileged insider: authenticated, authorized, and granted access to the data and tools it needs to do real work. And it can be turned against you without a single control being breached, because the attack does not arrive through the perimeter. It rides in on the very input the agent exists to process.

Security researcher Simon Willison named this 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 insider that can be instructed by a stranger. None of those three capabilities is a misconfiguration. Each one is the job description. Remove any leg and the agent stops being useful.

Authorized Is Not Safe

Authorization tells you who the agent is. It tells you nothing about what the agent can be talked into doing.

That is the inversion. SABSA can model an insider threat and can grade trust domain by domain — but every control it reasons about still resolves to a question of access: who is authorized to touch what, at what trust level. An agent defeats that frame without breaching any of it. It is authorized, correctly, for exactly what its job needs — and then manipulated, through the very input it exists to process, into using that authorization against you. The threat has moved below the access boundary, into behavior, where an access-control model has no native layer to stand on. The most trusted actor inside the boundary is now the least predictable one, and "authorized" has quietly stopped meaning "safe."

You Cannot Tighten Your Way Out

You cannot tighten your way out of it. The instinct is to clamp down on access, but access is not the failure. A fully authenticated, fully authorized agent, doing exactly what its permissions allow, is the attack surface. The failure lives one layer below access, in behavior: what a trusted worker is induced to do with authority it legitimately holds. SABSA controls the door. It has no layer for the badge-holder who was talked into walking the wrong file out.

Enforcement Moves to the Moment of Behavior

So security architecture has to add what SABSA never needed. 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 sits in the inference path between the agent and the models and tools it calls, governing what the agent is about to do rather than only whether it was allowed to connect. It inspects, constrains, and records behavior at runtime. That is a control layer the old security architecture did not have, because until now the enterprise never had to govern an insider whose loyalty was conditional on its last input.

The Badge Is Already Issued

SABSA secured the building by controlling the doors. The agent already has a badge. The question now is not who gets in, but what a trusted worker can be persuaded to do once inside.

The Bridge to Part 3

If the threat has moved below the access boundary into behavior, the next question is what that behavior is allowed to touch. Part 3 takes up capability governance: why API governance, built to manage systems, cannot govern what these workers compose.

About This Series

Michael K. Saleme — Enterprise Agent Architect

Part 2 develops the security consequence of the fifth domain. Where Part 1 asks who the workforce is, Part 2 asks what happens to a security architecture whose every control resolves to access.

This page is the canonical version of an essay also published to the Enterprise Agent Architecture newsletter.

Cite the Position Paper

This essay develops the Enterprise Agent Architecture position paper, which is published and peer-citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.

DOI: 10.5281/zenodo.21105314

Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314

BibTeX
@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}
}

Michael K. Saleme

Enterprise Agent Architect · Cognitive Thought Engine