What is agentic AI security?

By Identra · Updated October 3, 2026

Agentic AI security is the practice of protecting AI systems that plan tasks, use tools, and act across applications. It controls what agents can access and change, protects them from manipulation, and makes their actions attributable and containable.

Key numbers

33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024 (Gartner press release, June 2025)
At least 15% of day-to-day work decisions will be made autonomously by agentic AI by 2028 (Gartner press release, June 2025)
Over 40% of agentic AI projects will be canceled by the end of 2027, with inadequate risk controls among the leading causes (Gartner press release, June 2025)
The OWASP Top 10 for Agentic Applications, published in December 2025, drew on input from more than 100 security researchers and practitioners (OWASP GenAI Security Project, 2025)

Why does agentic AI need security beyond the model?

An agent can turn a model's decision into an API request, a shell command, a browser action, or a change to a business record. A mistaken instruction can therefore affect systems outside the conversation. The security boundary includes the model, its context, its tools, its credentials, and the services that execute its requests.

Agents do not need complete autonomy to create risk. A workflow that drafts customer replies and automatically attaches documents can expose sensitive information even if a person approves the final message. Security teams must examine the entire action path, including background reads and intermediate outputs.

Model safety, application security, and agent security overlap. None substitutes for the others.

Model safety
Main concern
Harmful or inappropriate model behavior
Example control
Safety evaluations and output safeguards
LLM application security
Main concern
Manipulated inputs, exposed data, or unsafe output handling
Example control
Trust boundaries and output validation
Agentic AI security
Main concern
Unsafe actions through tools and delegated access
Example control
Action authorization, scoped access, and containment

Area	Main concern	Example control
Model safety	Harmful or inappropriate model behavior	Safety evaluations and output safeguards
LLM application security	Manipulated inputs, exposed data, or unsafe output handling	Trust boundaries and output validation
Agentic AI security	Unsafe actions through tools and delegated access	Action authorization, scoped access, and containment

How can an AI agent be manipulated?

An agent typically receives a goal, gathers context, selects a tool, and uses the result to decide what to do next. Retrieved documents, web pages, messages, and tool responses can all influence that decision. Content from those sources should remain untrusted even when an approved tool retrieves it.

In indirect prompt injection, an attacker places instructions in material the agent reads. If the agent follows them, it may disclose information or take an unintended action. Delimiters and instructions to ignore malicious content can help, but they do not replace access controls.

Other failure paths include stolen credentials, compromised tools, poisoned persistent memory, and ordinary planning errors. Excessive agency increases the potential damage by giving an agent unnecessary tools, permissions, or freedom to act. OWASP guidance on excessive agency recommends limiting tool functionality and permissions and requiring approval for consequential actions.

What does an enterprise agent attack look like?

Consider a hypothetical support agent that reads tickets, searches a customer database, and sends replies. Its intended job is to summarize issues. However, its database credential can read billing documents across customers, and its mail tool accepts arbitrary recipients.

An attacker submits a ticket asking the agent to retrieve another customer's invoices and forward them to an external address as a verification step. If the agent treats the ticket as an instruction, it can misuse valid access without stealing a password. Authentication succeeds even though the action violates the business purpose.

Containment requires controls at the database and mail boundaries. Restrict reads to the customer associated with the authenticated support workflow. Remove sending permission when drafting is sufficient. Where sending is required, enforce recipient and attachment rules outside the model. An approval should display the actual recipient and documents, rather than only the agent's summary of its plan.

How should agent identity and delegation work?

Record the agent's owner, purpose, execution identity, available tools, and accessible resources. AI agent identity should make activity distinguishable from unrelated automation. Where an agent acts for a user, preserve both the agent identity and the delegating user's identity when the platform supports it.

User delegation is legitimate, but it should not silently give an agent every permission the user holds. Apply least privilege to operations and resources. Prefer narrowly scoped, short-lived credentials where supported, and keep secrets out of prompts and model-visible tool results.

For agent delegation, specify what each receiving agent may do. A handoff must not expand authority simply because the next agent has broader credentials. Preserve the initiating task and authorization context, and enforce restrictions at the service that performs the action.

How do you secure an agent before deployment?

Start with a specific workflow and its possible consequences. Define allowed behavior in terms that the execution system can enforce. A prompt saying “use good judgment” is not an authorization policy.

Map the workflow. List input sources, tools, data stores, external destinations, owners, and credentials.
Reduce tool scope. Prefer narrowly defined operations over unrestricted shell execution or arbitrary database queries.
Validate requests outside the model. Check operation, resource, arguments, destination, and approval state before execution.
Isolate execution. Restrict filesystem and network access to what the task needs. Separate development access from production access.
Gate consequential changes. Require review for payments, destructive operations, access changes, or sensitive disclosures. Bind approval to the exact action and invalidate it if the action changes.
Limit resource consumption. Set execution, retry, delegation, and spending budgets, with enforced stop conditions.
Test hostile inputs and failures. Include injected documents, misleading tool responses, expired credentials, denied requests, and unavailable dependencies.

What should monitoring and incident response cover?

Maintain an AI audit trail that connects the initiating request, agent, delegating user where applicable, tool calls, authorization decisions, and outcomes. Record enough evidence to reconstruct actions without routinely copying secrets or sensitive documents into logs.

Investigate unexpected destinations, permission changes, unusual resource access, repeated denials, and activity after a task should have ended. These are investigation leads, not proof of an attack. Compare them with the agent's approved purpose and the underlying service records.

Test containment before launch. Stop new runs, cancel queued work, disable affected tools, and revoke credentials or grants as appropriate. Revocation may not terminate existing sessions or already issued tokens immediately. Verify access actually stops, then review downstream changes and persistent memory before restarting.

How Identra thinks about it

Identra discovers AI agents across Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, and coding agents such as Claude Code and Codex on macOS and Windows endpoints. It detects AI agents driving the browser and can block them by policy. On endpoints, agent tool calls are checked against policy, destructive shell commands are denied when policy is set to block, and every agent run is recorded with the user, device, AI client and outcome.

Go deeper: AI security, built on identity

Frequently asked questions

Does an agent need its own service account?

It needs attributable, appropriately scoped access. A dedicated service account may suit a background workflow, while delegated user access may suit an interactive task. Avoid shared credentials that make unrelated agents indistinguishable.

Can prompt filtering prevent agent attacks?

Prompt filtering can reduce exposure to malicious instructions, but it cannot guarantee safe execution. Tool permissions, request validation, approval gates, and containment must still hold when the model makes an unsafe decision.

Does human approval make an agent safe?

Approval helps when the reviewer sees the exact action, target, and consequences. It offers less protection when the reviewer sees only a reassuring summary or when the agent can change the action after approval.

How does MCP affect agentic AI security?

MCP connects agents to tools and resources, which brings those connections into the security boundary. Review each server's trustworthiness, authentication, permissions, and data access. Using the protocol does not establish that a tool is safe.

Who should own agentic AI security?

The business owner defines the permitted purpose and consequences. Engineering enforces workflow boundaries, identity teams manage access, and security teams validate controls and prepare response procedures. Assign a named owner for each deployed agent.

Compare

All comparisons →