AI Became an Actor
For years, AI security was mostly a question about outputs: what the model says, what data it was trained on, what it might leak in a response. A model produced text, and a human decided what to do with it.
Agents change that. An agent decides, calls tools and APIs, and touches external systems. The output is no longer an answer. It is an action.
01 — From response to action
Traditional AI
User
AI Model
Response
Agentic AI
User
AI Agent
Decision
Tools / APIs
External Systems
Action
AI is moving from generating responses to taking actions.
Once a system can act, security stops being only about what it says and becomes about what it is allowed to do.
Every Action Needs an Identity
If an agent sends an email, updates a CRM record or queries a database, four questions matter: who asked, which agent acted, for which task, and what exactly was done. Without that chain, there is nothing to authorize and nothing to audit.
1Human user
The person or system on whose behalf the agent works
2Agent identity
A distinct, attributable identity for the agent itself
3Task / session
The scope and lifetime of the work being done
4Requested action
The specific tool call or operation being attempted
Shared service accounts and inherited user credentials blur this chain. An agent that borrows a human's full access can do anything that human can, for any reason, with no record of which agent did it.
Why Roles Are Not Enough
Role-based access control answers one question: what is this role allowed to touch? It works well when humans act slowly, predictably and inside a job description.
Agents act quickly, compose tools in ways nobody planned, and operate in changing context. The same action can be fine in one situation and dangerous in another.
02 — From RBAC to context-aware authorization
Traditional RBAC
User
Role
Permissions
Resources
Agentic authorization
Agent
+
User
+
Resource
+
Context
+
Action
+
Policy
Authorization decision
Allow
Deny
Require approval
Authorization increasingly depends on what is being done, by whom, and in what context.
The question shifts from "who are you?" to "can this agent do this action, on this resource, in this context?" Sometimes the answer is neither yes nor no, but "ask a human first."
Guardrails Influence. Controls Enforce.
Telling an agent "do not access sensitive data" is a guardrail. It shapes behavior, but the agent can still be wrong, manipulated or confused, and nothing stops the call if it goes ahead.
A security control sits outside the model. The agent's request is evaluated by a policy engine, and the tool is only reached if the answer is yes. Guardrails are worth having, but they are not a boundary.
The Agent Security Gate
The core idea is simple: the agent never talks directly to the tool. It requests, and a separate layer decides.
03 — The agent security gate
AI Agent
Action / tool request
Security Gate
Identity
Permissions
Policy
Context
Risk
Allow
continue to tool
Deny
block and log
External tool
The agent requests. The security layer decides.
Because the gate is independent of the model, it keeps working even when the model is wrong. That separation is the point.
MCP: Tool Access Is Capability Access
The Model Context Protocol gives agents a standard way to reach tools and systems. That makes it useful, and it also makes it an important place to enforce policy. Connecting an agent to a tool is granting it a capability.
MCP is not insecure by nature. It is an interface, and like any interface that connects intelligence to real systems, it needs identity checks, permission checks and policy evaluation in front of it.
04 — MCP as a security boundary
AI Agent
MCP request
MCP Security Layer
MCP Security Gateway
Policy Engine
Permission Check
Risk / Context Check
CRM
Database
Analytics
Internal APIs
Enterprise systems
Tool access is capability access.
Every Agent Action Needs a Trace
When an autonomous system takes an action, someone will eventually ask why. Logs of outputs are not enough. The full chain, from request to decision to execution, has to be reconstructable.
05 — Agent action trace
User
user_id
Agent
agent_id
Decision
task_id
Tool request
tool
Policy check
policy
Execution
timestamp
Result
outcome
Can we reconstruct why the agent did what it did?
This is the same discipline distributed systems already apply with tracing and audit trails, applied to decisions made by software that can reason.
More Agents, More Trust Relationships
One agent has one boundary to secure. Several agents, for example research, qualification, outreach and CRM agents coordinated by an orchestrator, bring many identities, many permission sets and many paths between them.
The questions multiply. Can these agents talk to each other? What can they share? Can one delegate an action to another? Can a low-privilege agent borrow the privileges of a high-privilege one? Securing agent-to-agent trust matters as much as securing agent-to-tool access.
Autonomy Should Be Granted, Not Assumed
Not every agent needs to act on its own. A useful way to think about it is a ladder, where each step up is earned by demonstrated reliability and justified by low risk.
Levels of agent autonomy
OBSERVE
Can see
RECOMMEND
Suggests
PREPARE
Creates action for approval
EXECUTE
Executes predefined actions
AUTONOMOUS
Decides within policy
Autonomy should be granted based on capability and risk.
The Agent Control Plane
Put these pieces together and a pattern appears. Between autonomous intelligence and real-world capability, there needs to be a dedicated layer that handles identity, permissions, policy, context, risk, runtime controls and audit in one place.
06 — The agent control plane
User
AI Agent → action request
Agent Control Plane
Identity
Permissions
Policy
Context
Risk
Runtime Controls
Audit / Observability
MCP
APIs
Databases
Action
From AI intelligence to controlled action.
The cloud world went through the same shift. Applications became too numerous and too dynamic to secure one by one, so control planes emerged. Agents are heading the same way.
What This Means for Enterprise AI
- Treat agents as actors with identities: Give each agent its own attributable identity rather than a borrowed human credential.
- Enforce outside the model: Put policy between the agent and every tool. Do not rely on instructions alone.
- Make autonomy earned: Start at observe or recommend, and move up as risk allows.
- Design for reconstruction: If you cannot trace an action, you cannot trust it.
"The agent requests. The control plane decides."
