Agentic AI security is the practice of controlling what AI systems that plan and act on their own may do, such as calling tools, changing data, sending messages, or spending money, and of proving afterwards what they did. The OWASP Agentic Security Initiative describes the shift plainly: unlike task-specific automation, agents plan, decide, and act across multiple steps and systems, often on behalf of users. The question changes from "is the answer correct?" to "what can this thing do if it is wrong, or if someone steers it?"

What changes when AI acts

A chat assistant produces text that a person reads. An agent takes the next step itself. Because a model cannot reliably tell instructions from the content it reads, OWASP lists Agent Goal Hijack as the first risk (ASI01) in its Top 10 for Agentic Applications 2026: hidden instructions in a web page, document, or email can redirect what the agent is trying to do. Joint guidance published on May 1, 2026 by CISA, NSA, and partner agencies says that autonomy and interconnectedness bring risks including privilege escalation, emergent behaviors, and accountability gaps.

This article covers the controls around the agent: autonomy, permissions, approval, trust between agents, memory, and monitoring. For the protocol-level view of tool connections, read What Is MCP? Architecture, Security Risks, and Technical Defenses. For the whole-system picture, read AI Security and AI Governance: Protect Every AI Component.

Decide how much autonomy each agent gets

Autonomy is a design choice, not a property of the model. A 2025 research paper by Feng, McDonald, and Zhang offers a useful vocabulary: five levels defined by the role the user plays, from operator (the user directs each action) through collaborator, consultant, and approver (the agent works alone and asks only at high-risk points) to observer (the agent runs everything, and the user has logs and an emergency off switch). It is a proposal, not a standard, but it makes the trade-off visible.

INFOGRAPHIC
Five levels of agent autonomy
Observer
agent runs all, user has logs and off switch
Approver
asks only at high-risk points
Consultant
agent leads, user advises
Collaborator
shared work, user can take over
Operator
user directs each action
Less human control (riskier)More human control

The joint guidance from CISA and its partners recommends that agents not be granted broad or unrestricted access, especially to sensitive data and critical systems. OWASP calls the same idea least agency. A practical rule: set autonomy by the worst thing the agent's tools can do, not by how capable the model seems. Read-only research can run with little supervision. Anything that moves money, deletes data, or messages outsiders should stay at the approver level or below, and autonomy should rise only on evidence from logs and testing.

Permissions and identity: give agents less

  • A separate identity for each agent: OWASP notes that an agent without its own governed identity works in an attribution gap, which makes true least privilege impossible. Treat agents as non-human identities. See Non-Human Identity and Service Accounts
  • Task-scoped, short-lived credentials: OWASP recommends narrow tokens issued per task and bound to the user, resource, purpose, and duration. Define per-tool scopes, rate limits, and egress allowlists, such as read-only queries and no send or delete rights for an email summarizer
  • Check at the moment of action: permissions validated at the start of a workflow can change before it ends. OWASP describes a purchase that completed on an old authorization after the user's spending limit was reduced
  • Do not hand full access to sub-agents: a manager agent that passes its whole access context to a narrow worker gives the worker far more authority than the task needs
INFOGRAPHIC
Agent permissions: common default versus safer design

Common default

  • Shared admin API keyno attribution
  • Long-lived tokenuseful to a thief for long
  • Checked once at startrights change, run goes on

Safer design

  • Own identity per agenttraceable and revocable
  • Short-lived, task-scoped tokenexpires when the task ends
  • Checked at each actionalways current policy

Human approval that actually works

OWASP calls for human approval of high-impact actions, and CISA's announcement calls for robust oversight mechanisms. The weak point is the human. OWASP's entry on Human-Agent Trust Exploitation (ASI09) warns that people over-rely on confident agents, and that a hijacked agent can fabricate a convincing rationale for a risky action.

  • Approve actions, not explanations: show the exact action, its arguments, and its expected side effects, ideally as a dry run or diff, rather than the agent's reasoning
  • Reserve approvals for what matters: delete, transfer, publish, external send, and permission change. OWASP lists oversight eroding through bulk approvals after repeated success as a route to cascading failure (ASI08)
  • Keep previews free of side effects: OWASP describes "read-only" previews that trigger webhooks when opened, so block network and state-changing calls during preview
  • Give a plain risk summary rather than a model-generated rationale, and let users flag suspicious behavior easily
INFOGRAPHIC
Path of a high-impact agent action
01
Agent proposes
action and arguments
02
Policy check
scopes, rate, allowlist
03
Human approval
high-impact steps only
04
Execute
short-lived credential
05
Log
tamper-evident record

Multi-agent systems: trust between agents

In a multi-agent system, a message from another agent looks like trusted internal traffic. OWASP's confused-deputy example shows the danger: a crafted email makes an email-sorting agent ask a finance agent to move money, and the finance agent trusts the internal request and pays without checking the original user's intent.

  • Authenticate agents to each other: per-agent credentials, mutual authentication, signed messages, and nonces or timestamps against replay (ASI07)
  • Do not inherit authority: the receiving agent checks the original user's intent and its own policy, not the sender's position
  • Separate planning from execution: an independent policy engine validates each high-impact step, and quotas and circuit breakers between planner and executor stop one fault from fanning out (ASI08)

Memory and state

Agents keep conversation history, summaries, embeddings, and retrieved documents. OWASP's Memory and Context Poisoning entry (ASI06) describes how corruption persists across sessions: an assistant's memory implanted through indirect prompt injection affects current and future sessions, and bogus entries in shared memory are reused by other agents.

  • Validate before writing to memory: scan new entries, and never automatically re-ingest an agent's own output into trusted memory
  • Segment memory: separate users, sessions, and domains, and wipe state between tasks that need different privileges
  • Track provenance and keep a way back: record each entry's source, expire unverified memory, and keep snapshots so poisoned memory can be rolled back

Monitoring, logging, and a kill switch

Agent activity can look legitimate. OWASP gives a scenario where an injected instruction makes an agent chain trusted administrative tools under valid credentials, so endpoint tools see no malware. Agents need their own telemetry.

  • Log every goal, tool call, and inter-agent message: use tamper-evident logs bound to each agent's identity
  • Baseline behavior and alert on drift: unexpected goal changes, unusual tool sequences, skipped validation steps, and permissions gained through delegation
  • Cap cost and rate: usage budgets with automatic throttling stop loop amplification and runaway bills
  • Build the off switch before you need it: kill switch, credential revocation, and quarantine, with a named person who can use them

Test adaptively. NIST's January 2025 write-up on agent hijacking evaluations reported that in its test setup, attacks tailored to the system raised attack success from 11% for the strongest baseline attack to 81%, and repeated attempts raised success further. A one-time benchmark is not proof of safety.

Fit it into governance

The NIST AI Risk Management Framework offers a simple structure: Govern, Map, Measure, Manage. For agents, Map means documenting each agent's purpose, tools, data, and autonomy level. Measure means red-teaming and adaptive testing. Manage means monitoring, incident response, and the ability to shut an agent down. Govern means a named owner for every agent. See What Is the NIST AI RMF? for the framework itself. Standards are still forming: NIST's CAISI launched an AI Agent Standards Initiative in February 2026, including work on agent security and identity, so check NIST for the current status before citing it.

INFOGRAPHIC
What to control for every agent
Agent under control
every agent has a named owner
Autonomy level
set by the worst action
Identity and permissions
one per agent, short-lived
Human approval
for what matters
Memory and trust
validate writes, authenticate peers
Monitoring and kill switch
logs, baseline, kill switch

Common mistakes

  • Treating the system prompt as the control: instructions can be overridden, so enforce limits in tools, identity, and policy outside the model
  • One shared service account for every agent: nothing can be attributed, and one compromise exposes everything
  • Approval on everything: people stop reading, and real risks pass unnoticed
  • Trusting internal agent messages: a compromised low-privilege agent can borrow a high-privilege agent's authority
  • Assuming existing monitoring covers agents: trusted tools under valid credentials do not look like malware

Start today

  • Inventory your agents: include those built into SaaS products and developer tools, and note which tools and data each can reach
  • Classify each by the worst action its tools can take, then set its autonomy level to match
  • Replace standing credentials with task-scoped, short-lived ones tied to a distinct agent identity
  • Put an approval gate in front of delete, send, pay, publish, and permission-change actions
  • Centralize logs and name who can stop an agent, then run one red-team exercise by planting an instruction in a document or email

To see how your wider controls compare, try the self-assessment for a prioritized view of next steps.

Simulating an attack on an agent with a deceptive instruction hidden in a document is part of red teaming, explained with its steps and rules in AI Red Teaming: How to Test AI System Security.

Agents that act through APIs face the same authorization problems; see API Security and the OWASP API Top 10 Explained.

References and further reading