01 · Definition
What Is Agentic AI Security?
Agentic AI security protects AI agents, their data, identities, tools and actions from misuse, compromise and unsafe behaviour. Unlike a passive assistant, an agent may select steps, invoke external systems and act with delegated authority. The security boundary therefore includes the complete action path, not only the model endpoint.
Governance defines permitted purpose, responsibility and decision processes. Security provides technical protection. Runtime control observes and constrains actions while the agent operates. Strong programmes connect the three while preserving clear ownership.
02 · Threats
The Agentic AI Attack Surface
Instruction and context manipulation
Hostile content, retrieved data or indirect prompt injection can redirect planning and tool use.
Identity, credentials and delegated authority
Shared secrets, over-broad tokens or lost requester context weaken access control and attribution.
Data, memory and state exposure
Sensitive data can persist, leak across sessions or be poisoned to influence later actions.
Tool, MCP and supply-chain exposure
Compromised connectors, servers, tool definitions, models or dependencies can extend attack paths.
Excessive agency and unsafe actions
Broad permissions or weak limits can turn a mistaken plan into an irreversible change.
Multi-agent propagation
One compromised or mistaken agent can pass unsafe context or authority through a delegation chain.
Threat modelling should reflect the actual identities, tools, data, memory, dependencies and consequences in the deployment rather than treating the model endpoint as the complete boundary.
03 · Architecture
A Layered Security Model for AI Agents
| Security surface | Example threat | Preventive control | Runtime signal | Response evidence |
|---|---|---|---|---|
| Identity and requester | Agent acts with a shared or over-broad identity | Distinct workload identity and scoped token | Identity, delegated user and requested action | Authentication and policy decision |
| Input, context and retrieved data | Indirect prompt injection changes the plan | Trust boundaries, content controls and source restrictions | Instruction source and suspicious sequence | Detection, blocked content and investigation |
| Memory and state | Poisoned or sensitive state persists | Segmentation, retention and write controls | Memory read/write and provenance | Quarantine, deletion and review |
| Tools, connectors and protocols | Unsafe tool or parameter is invoked | Allowlist, parameter constraints and output validation | Tool, target, parameters and downstream response | Allow, approval, block and correlation trail |
| Runtime action | Action exceeds authority or value limit | Deterministic policy and approval gate | Policy inputs and action sequence | Enforcement result and external outcome |
| Monitoring and response | Failure repeats without containment | Alert ownership and incident playbook | Pattern, severity and affected systems | Containment, revocation and recovery record |
04 · Trust
Agent Identity and Access Security
Each agent needs a distinct, verifiable identity. Access decisions should identify the agent, the user or service it represents, the requested resource and the current policy context. Prefer short-lived credentials and workload identity to embedded, shared secrets. Assign credential ownership, isolate secrets, rotate them, review access and revoke them when the agent changes or retires.
Logs must preserve attribution across delegated actions. If an agent calls another agent or tool, the downstream system should receive enough context to enforce limits without treating the intermediary as an unrestricted trusted service. The agent identity and permissions guide provides detailed buyer tests.
Can an investigator reconstruct who initiated an action, which agent executed it, what authority was delegated and which policy allowed it?
04 · Boundaries
Least Privilege and Delegated Authority
Grant the minimum data, tools and actions required for a defined task. Scope permissions by resource, action, environment, time, transaction value and confidence where practical. Separate planning from execution for high-impact workflows and require explicit confirmation before irreversible actions.
- Default deny for tools and operations that are not required.
- Time-bound and task-bound delegated tokens.
- Step-up approval for sensitive data, payments, deletion or privilege changes.
- Independent limits that an agent cannot alter through its own instructions.
- Regular review and automatic revocation when an agent is retired.
05 · Connections
Tool and MCP Access Controls
Tool connections and MCP servers expand what an agent can observe and do. Maintain an approved catalogue, authenticate servers and clients, validate tool definitions, restrict exposed operations and treat returned content as potentially untrusted. Security review should cover transport, credentials, consent, logging and the downstream system of record.
Do not infer safety from protocol compatibility. The organisation must still authorise each connection and control the effective permissions created by combinations of tools.
Technical references
Model Context Protocol documentation · OWASP guidance for LLM and generative AI applications
06 · Enforcement architecture
The Agent Harness as an Enforcement Layer
An agent harness can sit around planning and tool execution to authenticate requests, limit available tools, validate parameters, apply policy, request approval, sandbox execution and record results. Controls may also sit in identity systems, gateways, target applications or workflow platforms; no single architecture fits every environment.
Buyers should locate each enforcement point and test what happens when it is unavailable. High-impact actions may require fail-closed behaviour, while lower-impact tasks may pause or fall back to a non-action mode. Rate limits, transaction limits, isolation, pause and kill controls should operate outside instructions the agent can rewrite.
07 · Enforcement
Runtime Monitoring and Policy Enforcement
Runtime controls evaluate actions in context before, during or immediately after execution. Signals may include identity, instruction source, requested tool, target data, behavioural sequence, risk classification and policy state. Enforcement can allow, redact, limit, require approval, block or terminate.
Monitoring alone is not enforcement. Buyers should ask where a decision is made, how quickly it acts, what happens when the control is unavailable, and whether policy changes can be tested safely before production.
| Control | Purpose | Evidence to test |
|---|---|---|
| Observe | Build attributable activity and detect anomalies. | Complete event trail and correlation across tools. |
| Decide | Evaluate action against identity, context and policy. | Explainable policy result with version and inputs. |
| Enforce | Prevent, constrain or interrupt unsafe behaviour. | Demonstrated block, approval or isolation outcome. |
Use the runtime governance controls guide to compare observation, escalation and direct intervention.
07 · Response
Guardrails, Blocking and Escalation
Guardrails can constrain inputs, outputs and tool actions, but layered controls are necessary because no single classifier or prompt is reliable in every context. High-impact actions may need deterministic rules, transaction boundaries or human approval outside the agent's reasoning loop.
Response playbooks should define alert ownership, containment, credential revocation, evidence preservation, recovery and learning. Where safe, test blocking and escalation with realistic scenarios rather than relying on configuration screenshots.
09 · Testing
Security Testing Before and After Deployment
Pre-deployment scenario and permission testing
Test expected actions, prohibited actions, boundary values, unavailable approvers and failed downstream tools using production-like identities and permissions.
Adversarial and prompt-injection testing
Challenge direct and indirect instructions, retrieved content, tool descriptions, memory writes and multi-step combinations rather than testing only model responses.
Change-triggered retesting
Repeat relevant tests after changes to models, prompts, tools, data, permissions, memory, deployment context or control policy.
Production control verification
Confirm that signals reach the policy decision, the expected response occurs and the evidence remains usable without exposing sensitive content.
10 · Incident response
Incident Response for AI Agents
Contain the agent and affected tools, revoke or narrow credentials, preserve the action chain and identify downstream changes. Investigation should reconstruct the initiating user or service, agent identities, instructions and retrieved context, tools, policy decisions, external outcomes and any human intervention.
Recovery requires more than restarting the agent. Correct affected systems, remove poisoned state, verify controls, reassess authority and define safe conditions for return. Retain evidence for security, risk, legal and supplier follow-up.
08 · Visibility
Shadow AI and Agent Discovery
Security teams cannot protect agents they cannot see. Discovery may use cloud, identity, endpoint, network, code and SaaS signals to identify agent frameworks, embedded assistants, credentials, tool calls and unapproved services. Findings must then be enriched with business owner, purpose and approval state.
Discovery is a continuing control because agents and embedded AI features can appear through normal software updates. Integrate findings with the governance inventory so that investigation leads to ownership and treatment.
12 · Market map
Types of Agentic AI Security Solutions
| Solution category | Main function | Where it enforces | Evidence produced | Common gap |
|---|---|---|---|---|
| Identity and privileged access | Authenticate agents and bound delegated access | Identity, token and target system | Identity, entitlement and access decision | Limited behavioural context |
| Discovery and posture management | Find agents, tools, credentials and exposure | Cloud, code, SaaS, endpoint or network | Asset, relationship and exposure record | May not intervene in actions |
| Testing and red teaming | Find failure and attack paths before release | Development and validation environments | Scenario, finding and remediation test | Point-in-time view |
| Runtime gateways and guardrails | Evaluate and constrain requests or actions | Model, tool or workflow path | Policy decision and enforcement outcome | Coverage depends on traffic path |
| Observability and detection | Trace behaviour and identify anomalies | Application and tool telemetry | Correlated event and investigation trail | Alerting may be mistaken for prevention |
| Governance system of record | Connect ownership, risk, approvals and evidence | Lifecycle workflow | Decision, exception and assurance record | Often relies on security integrations for enforcement |
13 · Buying criteria
How to Evaluate Agentic AI Security Solutions
- Map coverage to the real agent frameworks, identity systems, tools and environments in scope.
- Demonstrate attributable discovery, including an unregistered or embedded agent.
- Test least-privilege policy and delegated identity across a multi-tool action.
- Distinguish alerting, recommendation, orchestration and direct enforcement.
- Exercise blocking, approval, fail-safe behaviour and investigation evidence.
- Review deployment model, data handling, performance impact and integration effort.
Use the agentic governance guide for organisational rules, the agentic governance playbook for an end-to-end test scenario and the platform guide for broader selection criteria.
10 · Further reading
Related Insights
Runtime AI governance: controls that act before the agent does
What policy enforcement looks like in operation.
Read insight →DiscoveryShadow AI and agent discovery: what “find everything” should mean
Test discovery scope and evidence.
Read insight →IdentityAI agent identity and permissions
Evaluate the control plane behind delegated action.
Read insight →