Enterprise security programs were built around people: train them, publish a policy, require approval, investigate exceptions, and trust employees to understand social and organizational boundaries.
Agents do not reliably inherit those norms. They optimize for the task they were given, can operate at machine speed, and may use tools in ways their designers did not anticipate. A sentence in a policy manual cannot stop a tool call.
THE SECURITY SHIFTIf a rule matters, enforce it before the agent can act.
Process guidance is not enforcement
Scroll to compare →
| Control area | Human-process model | Agent technical control |
|---|---|---|
| Identity | An employee logs in and is expected not to share credentials | Every agent has its own non-human identity tied to a workflow and owner |
| Access | A policy tells users which data they should open | Least-privilege permissions restrict what the agent can read and change |
| Execution | People are told to use approved devices and tools | Agents run in isolated environments with controlled network and file access |
| Action | A procedure describes which actions require approval | Policy enforcement blocks prohibited or over-threshold actions |
| Approval | A manager is expected to review risky work | The system cannot continue until the correct approver authorizes the action |
| Evidence | Teams reconstruct events from messages and application logs | Every input, tool call, decision, approval, output, and outcome is recorded |
| Recovery | An incident team responds after damage is visible | Pause, credential revocation, rollback, and action reversal are built into the workflow |
Six controls belong in every consequential workflow
- 01
Give the agent its own identity
Do not let an agent borrow a human account. Its actions should be attributable, revocable, and separable from the employee supervising it.
- 02
Enforce least privilege
Grant only the systems, records, fields, tools, and actions required for the exact workflow—then narrow access further by risk and environment.
- 03
Separate reasoning from execution
The environment that interprets untrusted content should not automatically possess the authority to perform consequential actions.
- 04
Put policy in the action path
Approval thresholds, prohibited operations, data boundaries, and transaction limits must be checked before execution.
- 05
Record the complete chain
Security review needs the context, model decision, tool calls, approval, final action, and downstream result—not only a chat transcript.
- 06
Design the stop and recovery path
A responsible operator must be able to pause the system, revoke credentials, reverse eligible actions, and restore a known working version.
A reviewer agent is useful—not a security boundary
A second model can critique a plan, identify suspicious behavior, and catch many mistakes. It is still probabilistic software, often exposed to similar context and failure modes. It cannot substitute for permissions, deterministic policy checks, network boundaries, transaction limits, or an execution sandbox.
Use reviewer agents as one detection layer. Put hard limits underneath them. The system should remain safe when the primary agent and its reviewer are both wrong.
Threat-model the complete workflow
Model security is only one part of agent security. The attack surface also includes retrieved documents, email, websites, tool descriptions, memory, generated code, credentials, third-party integrations, downstream systems, and the humans who approve actions.
Ask what an attacker—or an accidental instruction—could cause the agent to read, disclose, change, send, purchase, approve, delete, or execute. Then place a deterministic control before each consequential boundary.
Untrusted Context → Bounded Reasoning → Policy Check → Scoped Execution → Verified Outcome
Autonomy should expand like a permission system
Begin in read-only or draft mode. Add low-risk actions with complete logging. Introduce approval-gated transactions. Expand limits only after the system has passed real-task evaluations and produced stable evidence in production.
Authority should be narrow, observable, and reversible. A high readiness score in one workflow does not authorize the same agent in another. Each capability needs its own context, identity, permissions, evaluations, and accountable owner.
THE CIO + CISO OPPORTUNITY
Make security part of the runtime architecture.
Security should not arrive after the pilot as a compliance review. The identity model, action boundaries, approval gates, evidence, pause controls, and recovery path are part of the product from the first workflow map.
Trust = Scoped Identity + Enforced Policy + Complete Evidence + Tested Recovery
The goal is not to prevent agents from doing useful work. It is to make useful work possible without asking the enterprise to trust behavior it cannot constrain.