Agentic AI security is the discipline of protecting AI systems that can take action. Not AI systems that generate text, but AI systems that plan steps, call tools, request credentials, access databases, modify code, deploy infrastructure, and operate on behalf of humans inside real production systems.
The distinction matters because the security surface is fundamentally different. When an AI only generates text, the risk is whether the output is correct, harmful, or misleading. When an AI can act (when it can call your AWS APIs, run shell commands against your infrastructure, query your production database, or open a pull request that triggers a deployment pipeline) the risk extends to everything that action can reach. The question shifts from “is the output safe to read?” to “should this action be allowed to execute?”
Agentic AI security sits at the intersection of identity security, access management, data protection, and runtime governance. It borrows from each but is not reducible to any one of them, because the thing being secured (an AI system that plans and acts with non-deterministic behavior) does not fit neatly into controls designed for humans or traditional software.
What makes an AI system agentic
AI systems exist on a spectrum of autonomy. At one end, autocomplete suggests the next few tokens. In the middle, a copilot proposes code changes that a human reviews and accepts. At the far end, an autonomous agent plans a multi-step workflow, selects tools, requests credentials, executes actions, evaluates results, and iterates — all with minimal human intervention.
An AI system becomes agentic when it has some combination of:
- Tool use — the ability to call functions, APIs, CLIs, or external services
- Credential access — the ability to request, hold, or use credentials to authenticate to systems
- Multi-step planning — the ability to decompose a goal into actions and execute them in sequence
- Memory and context — persistent workspace state across actions within a session
- System-of-record access — the ability to read from and write to databases, file systems, cloud resources, and SaaS applications
The more of these capabilities an agent has, the larger its security surface. Claude Code reading a repository and running CLI commands is agentic. Cursor calling cloud APIs to provision infrastructure is agentic. An internal automation agent authenticating to your CRM, reading customer data, and triggering workflows is agentic. Each of these requires security controls proportional to the authority the agent holds.
The threat model for agentic AI
Agentic AI introduces a threat model that has no direct precedent in traditional application security or infrastructure security. The threats are not theoretical, they map to the architecture of how agents actually operate today.
Credential exposure
AI agents need credentials to interact with systems. In practice, those credentials often show up as long-lived AWS access keys in ~/.aws, database connection strings in .env files, SaaS API tokens in MCP server configurations, and cloud admin credentials embedded in agent environments. The blast radius of these credentials extends across every system they can access, for the full lifetime of the key — not the seconds the agent actually needed them.
The fix is architectural: agents should never hold standing credentials. They should request scoped, short-lived access for each operation through a JIT broker and have that access revoked immediately after use.
Over-permissioned actions
Agents receive broad access because scoping is hard and broad access avoids friction. A coding agent that needs to read one table gets database admin credentials. An automation agent that deploys one service gets AdministratorAccess. The permissions are granted once, under time pressure, and never revisited.
The result is that every action the agent takes runs with the full authority of its over-permissioned identity, not with the narrow permissions the specific task requires. A prompt injection, a hallucinated action, or a compromised tool connection can then reach everything those broad permissions allow.
Prompt injection
Prompt injection is the attack that is unique to agentic AI. Untrusted content e.g. a malicious code comment, a crafted file in a repository, a poisoned response from an MCP server, text in a webpage the agent reads can steer the agent to perform actions it was not instructed to take by the human operator.
In a text-only AI, prompt injection produces misleading output. In an agentic AI with tool access and credentials, prompt injection produces unauthorized actions: data exfiltration, credential theft, infrastructure modification, or lateral movement. The severity scales directly with the agent’s permissions.
Supply chain risk through MCP servers
The Model Context Protocol (MCP) lets agents connect to external tools and data sources through a standardized interface. Each MCP server an agent connects to expands what the agent can do and what an attacker who influences the agent can reach.
MCP servers are the agentic supply chain. Shell-launched servers with broad filesystem mounts, over-permissioned database connections, and unvetted third-party servers all expand the agent’s blast radius. Installing a new MCP server is a trust decision equivalent to adding an unreviewed dependency to your production codebase.
Shadow AI and unmanaged agents
Shadow AI is the use of AI tools, agents, and model connections inside an organization without security’s knowledge or approval. Developers install coding agents, configure MCP servers, and wire up tool integrations on their local machines without any central inventory or governance.
The problem is not that developers use AI. The problem is that security cannot protect what it cannot see. An unmanaged agent holding production credentials, connected to unvetted MCP servers, with no action governance and no audit trail, is an unmonitored identity with broad access the exact thing security teams spend years trying to eliminate from their environment.
Data exfiltration through prompts
When an agent gathers context to solve a problem, it reads files, configurations, and system state — then sends that context to an external model provider as part of a prompt. Without a control on the egress path, secrets, PII, proprietary source code, and internal architecture details flow to a third-party model provider silently.
Traditional DLP was built for email, endpoints, and network egress. It does not sit on the path between a coding agent and a model provider. Agent-specific DLP that intercepts prompts and tool arguments before they leave the device is required to close this gap.
Action ambiguity and missing audit
When an agent takes an action such as deleting a resource, modifying a configuration, or accessing sensitive data; the audit log often shows only the credential that was used, not the human who initiated the session, the prompt that triggered the action, or the business justification. CloudTrail says svc-deploy deleted the bucket. Which agent? Which engineer’s request? Which prompt triggered it? The trail ends at the credential.
Without identity attribution that chains agent → human operator → policy → action → resource, incident response and compliance audits are blind.
Lateral movement through agent identity
A compromised agent whether through prompt injection, a malicious MCP server, or a supply chain attack, can move laterally using its stored credentials and tool connections. If the agent has standing access to multiple systems (cloud APIs, databases, SaaS applications, internal services), a compromise of the agent’s session gives the attacker access to all of those systems simultaneously.
The lateral movement risk of an agent is defined by the same blast radius concept that applies to any other identity: what can this identity reach if compromised? For agents with broad, standing credentials and multiple MCP server connections, the answer is often: a lot.
Why traditional security controls don’t cover agentic AI
Existing security controls were designed for a world where humans initiate actions and software behaves deterministically. Agentic AI breaks both assumptions.
- IAM alone is insufficient. IAM defines what permissions an identity has, it does not govern what actions the identity is actually taking, in real time, or whether those actions are appropriate given the current context. An agent with
s3:*is allowed to read any bucket; IAM cannot distinguish between a legitimate read the developer requested and an exfiltration triggered by prompt injection. - Network controls miss the agent-to-model path. Agent traffic to model providers travels over HTTPS to well-known endpoints. It looks like normal API traffic. Network security sees an HTTPS connection to
api.anthropic.comit cannot see that the request body contains your AWS access keys and production database schemas. - SIEM and UEBA baselines break. Traditional behavioral analytics baseline normal patterns and flag deviations. Agent behavior is inherently variable. Each session is different depending on the prompt, the repository state, and the planning decisions the model makes. Baselines built for deterministic service accounts fail when applied to non-deterministic agents.
- Code review doesn’t see runtime actions. An agent that runs shell commands, calls cloud APIs, or modifies infrastructure takes actions that never appear in a pull request. Code review governs what gets merged; it cannot govern what the agent did between receiving a prompt and producing a result.
- Endpoint DLP doesn’t sit on the egress path. Traditional endpoint DLP monitors file copies, USB transfers, and email attachments. It does not inspect the content flowing from a coding agent to a model provider through an MCP connection or a direct API call.
- LLM gateways govern model traffic, not actions. An LLM gateway proxies traffic to and from the model enforcing rate limits, content policies, and token budgets. It does not see the agent pick up a cloud SDK and start making real infrastructure changes based on the model’s response.
The gap is clear: existing controls were designed for humans using applications and software executing code. They were not designed for AI systems that plan, hold credentials, and act across multiple systems with non-deterministic behavior.
The security architecture for agentic AI
Securing agentic AI requires a layered architecture where each control covers a specific part of the agent’s lifecycle and authority. No single control is sufficient; the architecture is the combination.
Identity and attribution
Every agent needs a distinct identity — not a shared service account, not the developer’s personal credentials. That identity must be tied back to the human operator so every action produces an audit trail that chains: human → agent → policy decision → tool call → resource → outcome.
In practice, this means agent registration (name, use case, owning human), a first-class identity in your non-human identity inventory, and attribution in audit logs (CloudTrail, database audit, SaaS logs) that connects the agent action to a specific human session.
Credential management through JIT
Standing credentials in agent environments are the single largest risk factor in agentic AI. Replacing them with Just-In-Time access is the highest-leverage control available.
The pattern: the agent requests access for a specific operation (“I need to read table X in database Y for 5 minutes”). A JIT broker evaluates the request against policy — scope, environment, blast radius, identity of the human, history of the agent. If approved, it issues a short-lived, narrowly-scoped credential. The agent uses it. The credential is destroyed when the operation completes or the TTL expires.
The agent never holds a standing key. The blast radius of any compromise is bounded to the duration and scope of the active JIT session, not the lifetime of a stored credential.
Action governance
Action governance is the real-time control that evaluates each tool call an agent attempts, and decides whether to allow, block, gate, or redact it. This is the coding agent firewall layer.
The evaluation considers: what action is being attempted? Against which resource? In which environment? By which agent, on behalf of which human? What is the blast radius if this action goes wrong? Is this a read (generally safe) or a destructive write (needs approval)?
Policy-driven decisions:
- Allow: Low-risk operations (reads in non-production) proceed without interruption
- Block: Destructive or prohibited actions (dropping tables, deleting infrastructure) fail closed
- Gate: Risky but legitimate operations pause for human approval through Slack, Teams, or email
- Redact: Sensitive content in the action’s arguments is stripped before forwarding
Data protection
DLP for agentic AI operates on the device, on the path between the agent and the model provider. It intercepts outbound prompts and tool arguments, scans for secrets, PII, and sensitive file content, and blocks or redacts before anything reaches the external model.
This control is distinct from network DLP or endpoint DLP because it sits specifically on the agent’s egress path — the connection between the coding agent process and the model API. Traditional DLP cannot see this traffic because it looks like normal HTTPS API calls.
Supply chain governance
Every MCP server connected to an agent is a supply-chain dependency. Governance means: inventorying every connected server, flagging high-risk patterns (shell-launched servers, broad filesystem mounts, over-permissioned credentials), vetting new servers before connection, and treating server responses as untrusted content that could carry prompt-injection payloads.
Discovery and inventory
You cannot secure agents you do not know about. Discovery means fleet-level visibility into which agents are installed, which MCP servers are connected, which model providers are called, and which credentials are accessible — across every developer machine and CI/CD environment in your organization.
This is the shadow AI problem: the agents and tools that are already running, unmanaged, on developer machines. Discovery brings them under governance.
Behavioral detection
Agent actions should be monitored like any other non-human identity. Baseline normal patterns, flag deviations, correlate with threat intelligence. An agent that suddenly starts accessing resources it has never accessed before, from an unusual context, with a spike in API call volume, warrants investigation.
The challenge is that agent baselines are looser than service account baselines (because agent behavior varies by prompt). The solution is correlating behavioral signals with identity context, blast radius, and threat intelligence — the same graph-based approach that filters noise in cloud UEBA.
Audit and compliance
Every action an agent takes — whether allowed, blocked, gated, or redacted — produces an identity-stamped audit record. That record links the agent, the human operator, the policy that fired, the resource that was touched, and the outcome. This chain is the foundation for incident response, compliance evidence, and access reviews.
Agentic AI security across the lifecycle
Security controls for agentic AI map to three lifecycle phases:
Pre-deployment
Before an agent begins operating, establish the security boundary:
- Register the agent with a distinct identity and owning human
- Define the agent’s cloud boundary: which accounts, which roles, what maximum session duration
- Vet and approve MCP server connections as supply-chain decisions
- Configure the action governance policy: what is allowed, what is blocked, what requires approval
- Remove standing credentials from the agent’s environment
Runtime
While the agent is operating, enforce controls in real time:
- Broker credentials through JIT for each operation, with automatic revoke on completion
- Evaluate each tool call against action governance policy (allow/block/gate/redact)
- Inspect outbound prompts for sensitive data before they reach the model
- Enforce human-in-the-loop approval for high-risk operations
- Monitor behavioral patterns for anomalies
Post-action
After the agent completes work, ensure accountability:
- Audit trail links every action to a human operator and a policy decision
- Anomaly detection evaluates the session against baseline behavior
- Blast radius assessment calculates what the agent could have reached during the session
- Compliance evidence is generated automatically from the audit trail
- Access reviews include agent identities alongside human and service account reviews
Agentic AI and non-human identity
AI agents are non-human identities. They authenticate to systems, hold permissions, and take actions — exactly like service accounts, CI/CD roles, and Lambda execution roles. They belong in the same identity inventory, subject to the same governance: lifecycle management, access reviews, dormancy detection, permission right-sizing, and blast radius assessment.
But they differ from traditional NHIs in important ways:
- Non-deterministic behavior: A service account runs the same code path every time. An agent’s behavior varies based on the prompt, the context, and the model’s planning decisions. This makes behavioral baselines harder to establish.
- Human-influenced: An agent acts on behalf of a human operator, and its actions are shaped by that human’s instructions. The identity chain is two-layer: human → agent → action. Traditional NHIs have no human in the loop at runtime.
- Context-dependent risk: The same agent can be low-risk (reading documentation) or high-risk (deploying infrastructure) depending on the prompt it receives. Its risk profile is dynamic within a single session.
- Prompt-injectable: Traditional NHIs execute code that has been reviewed and deployed through a pipeline. Agents execute actions influenced by natural language input, which can be manipulated by untrusted content.
These differences mean that while agents belong in your NHI inventory and governance framework, the controls applied to them must account for their unique characteristics — particularly the need for real-time action governance and JIT credential brokering rather than static permission assignment.
Common implementation patterns
Pattern 1: JIT credential brokering over MCP
The agent makes an intent call over MCP: “I need to read table X in database Y for reason Z, for N minutes.” A JIT broker evaluates the request against policy — scope, blast radius, environment, identity of the human. If approved, short-lived credentials are issued scoped to exactly that action. Credentials are destroyed when the operation completes or TTL expires.
Pattern 2: On-device action guardrail
A guardrail runs on the developer’s machine and hooks into the agent’s tool-call pipeline. Every action the agent attempts — file writes, shell commands, API calls — passes through the guardrail first. Policy decides: allow, block, gate, or redact. The guardrail operates independently of the agent and cannot be bypassed by the developer casually dismissing a prompt.
Pattern 3: Shadow-AI discovery
A fleet-level scan inventories every AI tool, MCP server, IDE extension, and model connection running on developer machines. Unmanaged agents are identified, categorized by risk (based on what credentials and systems they can access), and brought under the same governance policy as managed agents.
Pattern 4: Human-in-the-loop approval for risky operations
High-risk operations — writes to production, destructive actions, access to sensitive data — trigger a human approval gate. The approval request arrives via Slack, Teams, or email with full context: what the agent wants to do, which resource, which human initiated the session, and what the blast radius is. The human approves once, for this specific operation only.
Pattern 5: Tiered policy by environment
Reads in development environments auto-approve with minimal credentials and no approval gate. Writes in staging require scoped credentials with a short TTL. Writes in production require human-in-the-loop approval, tighter scoping, and full audit. The same agent operates across all environments; the policy adapts to the risk level.
Agentic AI security vs. adjacent disciplines
The boundaries between agentic AI security and related disciplines are worth drawing clearly.
vs. AI safety: AI safety concerns alignment, values, harmful outputs, and long-term societal impact of AI systems. Agentic AI security concerns credentials, actions, data, permissions, and systems access. A safe model that gives helpful, harmless answers can still be insecure if it holds admin credentials and has no action governance.
vs. LLM security (OWASP LLM Top 10): LLM security covers the model itself — prompt injection, training data poisoning, model denial of service, insecure output handling. Agentic AI security covers what the agent does with the model’s output: the tool calls, the credential use, the system access. The two are complementary layers; neither subsumes the other.
vs. application security: AppSec secures the code your team writes — vulnerabilities, dependencies, secrets in source. Agentic AI security secures the actions an AI takes with your systems at runtime. A codebase can be perfectly secure while the agent operating on it has excessive permissions and no action governance.
vs. endpoint security: Endpoint security protects the device — malware, unauthorized software, data exfiltration via traditional channels. Agentic AI security governs what the agent on that device can reach: which cloud resources, databases, and APIs it can access, and what actions it is allowed to take.
Frequently asked questions
What is agentic AI?
Agentic AI refers to AI systems that can plan and take actions through tools, APIs, code execution, or workflows — not just generate text. A coding agent that reads your repository, runs CLI commands, and calls cloud APIs is agentic.
What is the difference between agentic AI security and AI safety?
AI safety focuses on alignment, harmful outputs, and societal impact. Agentic AI security focuses on credentials, permissions, actions, data protection, and system access. Both matter; they protect against different categories of risk.
How is agentic AI security different from LLM security?
LLM security (OWASP LLM Top 10) covers attacks on the model itself — prompt injection, training data poisoning, model denial of service. Agentic AI security covers what the agent does with the model’s output: the tool calls it makes, the systems it accesses, the credentials it uses. They are complementary layers.
Should AI agents have permanent credentials?
No. Agents should use short-lived, scoped credentials issued through a policy-controlled JIT workflow for each operation. Standing credentials in agent environments are the single largest risk factor because they define the blast radius of any compromise for the full lifetime of the key.
What is the biggest risk with agentic AI?
Over-permissioned agents with standing credentials and no action governance. An agent with admin-level access to production, no approval gates, and no credential expiry combines maximum blast radius with maximum exposure window. The fix is JIT credentials, action governance, and least privilege.
How do you audit AI agent actions?
Through identity-stamped audit records that link every action to the agent identity, the human operator, the policy decision (allow/block/gate), the resource touched, and the outcome. This requires agent registration with distinct identity, attribution in cloud and database audit logs, and a governance layer that records every policy evaluation.
What is an MCP server and why does it matter for security?
An MCP server is a component that exposes tools, data, or system access to an AI agent through the Model Context Protocol. Each connected MCP server expands what the agent can do and what an attacker who influences the agent can reach. MCP servers are the agentic supply chain.
Can existing security tools protect agentic AI?
Partially, but not sufficiently. IAM defines permissions but cannot govern real-time actions. Network controls miss agent-to-model traffic. SIEM baselines break on non-deterministic behavior. Endpoint DLP doesn’t sit on the agent egress path. Agentic AI security requires purpose-built controls: JIT credential brokering, real-time action governance, agent-specific DLP, and MCP supply-chain management.
What is the first step to securing AI agents in my organization?
Discovery. Inventory the AI agents, MCP servers, and model connections already running in your environment the shadow AI you cannot currently see. Then establish distinct identities for each agent, remove standing credentials, and implement action governance with audit. The path from there is JIT credentials, DLP, and behavioral monitoring.
