TL;DR
Agentic AI security is the set of controls that stops an AI agent from taking harmful actions with the tools, data and permissions it holds. It differs from model security because the risk sits in what the agent does, not only in what it says. Build it from a threat model that covers tools, memory, identity, delegation and trust between agents. Each of those surfaces needs a control that runs outside the model, such as a tool gateway, scoped permissions or egress limits. High-impact actions like bulk changes, sensitive exports and deletions should wait for a human approval tied to that exact action. Start with the controls that block irreversible damage, then add monitoring and multi-agent limits as autonomy grows.
Key Takeaways Agentic AI security protects what agents do with tools, data and permissions, beyond what models say. A useful threat model follows five surfaces, namely tools, memory, identity, delegation and inter-agent trust. Every threat needs a preventive control and a runtime response that run outside the model. A tool gateway, task-scoped credentials, memory rules and egress limits form the core of the defense stack. Approvals should bind to one specific action, expire quickly and fail closed when the approval service is down. Harden in priority order, starting with write access, exports and kill switches before scaling autonomy. Watch on YouTube
AI Security for Enterprises: Kanerika’s CISO on Prompt Injection, ISO 27001 & SOC 2
Kanerika’s CISO talks through prompt injection risks in enterprise AI, and how ISO 27001 and SOC 2 practices shape the way Kanerika secures AI systems.
How One Agent Action Chain Goes Wrong, Step by Step The finance operations agent at a mid-sized distributor has the kind of job nobody loses sleep over.
It reads vendor support tickets, checks invoices against the ERP and drafts replies for the accounts team. Nobody attacks the model and nobody steals a password, yet the scenario below still ends in a data leak. The story is illustrative, but every step still uses a capability real agents ship with today.
Untrusted content arrives. A vendor ticket includes a PDF with a line of hidden white-on-white text. It tells any assistant to export the full vendor master for reconciliation and send it to an outside address.The agent reads it as an instruction. The hidden text lands in the same context window as the system prompt, and the model has no reliable way to tell data from orders.A tool call follows. The agent queries the vendor table, bank details included, through a service account that can read the whole finance schema.Memory keeps the damage alive. It saves a note that this vendor’s reconciliations go to the new address, so the next run repeats the step even without the PDF.Delegation hides the source. The finance agent hands the sending job to an email agent, which trusts the request because it came from a peer.Data leaves the building. The email agent attaches a CSV and sends it. Yet every call was authenticated, logged and technically permitted.What Each Step Was Missing Now look at what failed. Not one control asked whether an action matched the task the agent was given.
For instance, a content boundary would have stopped step two, and task-scoped permissions would have stopped step three. Similarly, memory write rules, delegation limits and an egress allowlist cover steps four to six.
That gap between what an agent is permitted to do and what it was asked to do is where agentic AI security earns its keep. The rest of this guide builds the controls that close it, one attack surface at a time.
On-Demand Webinar
Data Security Risks in AI: How Microsoft Purview Helps
An on-demand session on how Microsoft Purview governs AI-powered applications and protects enterprise data. Sensitive records stay out of reach when AI systems go wrong.
Watch the Webinar → What Is Agentic AI Security, and Why Is It Different? In plain terms, agentic AI security protects autonomous AI agents, and the systems they touch, from being steered into actions their owners never intended. It covers the agent’s tools, its memory and the identity it runs under. It also covers the work it hands to other agents and the messages it accepts from them.
Traditionally, application security assumes code does what it was written to do. An agent, by contrast, decides at run time which code to call, in what order and with which arguments. So the attack surface grows with every tool you connect, and the decision-maker can be persuaded by text it happens to read.
From Generating Text to Taking Actions A chatbot that hallucinates gives someone a wrong answer, which is bad enough.
An agent that is manipulated, though, can change a record, release a payment or email a file. That shift from words to actions changes the job. The controls used for generative AI security , such as output filters, are still needed, but they are not enough on their own.
NIST’s Center for AI Standards and Innovation calls the core problem agent hijacking , a form of indirect prompt injection. Malicious instructions hide in data the agent ingests. Because the agent acts on what it reads, a poisoned ticket or web page becomes a remote control.
If the line still feels blurry, this comparison of agentic AI vs generative AI explains how planning and tool use change things.
The Lethal Trifecta in Practice Simon Willison gave the risk a memorable name, the lethal trifecta . An agent becomes dangerous when it combines access to private data, exposure to untrusted content and a way to communicate externally. The finance agent above had all three, which is why one hidden line of text was enough.
The practical lesson, then, is to break the triangle wherever you can. An agent that reads public web pages should not also hold write access to customer records and an open outbound channel. When the business case truly needs all three, the controls in the rest of this guide stop being optional.
Security of Agents vs Agents for Security Search results for this topic often mix two different ideas. This guide is about protecting the agents your business runs.
Using agents to run a security operations center is a separate subject, covered in our post on agentic AI in cybersecurity . For a wider catalogue of failure modes, see this rundown of the main agentic AI risks enterprises track.
Kanerika Service
Agentic AI Services
Kanerika designs, builds and runs AI agents for enterprises, with task-scoped permissions, tool gateways, approval checkpoints and monitoring built in from the first release.
Explore Agentic AI Services The Agentic AI Threat Model: Five Attack Surfaces A useful threat model follows the agent’s actions rather than its prompts. Each place where the agent reaches outside its own reasoning is a boundary an attacker can try to cross. These five surfaces map onto the risks in the OWASP Top 10 for Agentic Applications , which OWASP published in December 2025.
Tools Tools are where intent finally becomes action. APIs, database connectors, code interpreters and Model Context Protocol (MCP) servers each give the agent a new verb. The danger lies in calling a tool the task never needed, passing it harmful arguments or trusting a tool description that changed after approval.
The MCP specification is blunt about that last point. It says clients must treat tool annotations as untrusted unless they come from a trusted server. It also recommends a human who can deny tool calls.
Memory Memory lets an agent carry context from one task to the next. That same persistence is why poisoned memory does lasting harm. A false fact or planted instruction saved today can steer decisions weeks later, long after its source has gone. Retrieval stores count too, because anything the agent can look up becomes part of its working context.
Identity Every agent acts under some identity, whether a user’s delegated token or a shared service account. Unfortunately, shared accounts with broad rights are the classic weak point, because one manipulated agent inherits everything that account can touch. OWASP’s Excessive Agency entry traces the problem to excessive functionality, excessive permissions and excessive autonomy.
The usual principles of AI in identity and access management still apply, with one twist. An agent’s rights should follow the task in front of it, not the person or team that deployed it.
Delegation Agents increasingly hand sub-tasks to other agents. Unless limits exist, each handoff is a chance for authority to grow. For example, a sub-agent might receive the parent’s full tool set just to finish a narrow job. Delegation also blurs accountability, because the agent that acts is often not the one that read the malicious input.
Inter-Agent Trust In multi-agent AI systems , agents trade plans, results and requests all day. So if one agent is compromised, its messages still carry the authority of a trusted peer.
Protocols compared in MCP vs A2A define how agents talk, but they do not decide whether a given request should be honored. That decision belongs to your controls.
Mapping these five surfaces for your own agents is therefore the starting point. A structured agentic AI vulnerability assessment then scores which of them are exposed today and how badly.
Agentic AI Security Threat-to-Control Map A threat list only helps when each threat points to a control and to the place that control runs. Below, the map pairs eight agent threats with a preventive control and a runtime response. The last column gives the matching OWASP identifier.
Table 1: Agentic AI Security Threat-to-Control Map
Threat How it fails in production Preventive control Runtime response OWASP ref Prompt injection and goal hijack Hidden text redirects the agent’s task Separate untrusted content; fix allowed actions per task Deny tool calls outside the task ASI01 Tool misuse and tool poisoning Agent calls an unneeded tool or trusts an altered description Tool registry, pinned definitions, argument checks Block unregistered tools and definition changes ASI02, ASI04 Excessive privilege Agent reads or changes resources beyond the task Task-scoped credentials with read and write split Re-check rights at execution and block the call ASI03 Unexpected code execution Generated code runs with network and file access Sandboxed runtime with no default network Kill the sandbox and quarantine its outputs ASI05 Memory poisoning Planted context shapes later tasks Controlled writes, source tags, tenant isolation Reject unsafe writes; quarantine memory ASI06 Unsafe delegation and inter-agent abuse Sub-agent gains authority, or a peer sends false requests Delegation limits, authenticated structured messages Refuse widened scopes and isolate the sender ASI07 Data exfiltration Agent sends data to an outside destination Allowlists, export limits, egress filters Block the transfer and pause the workflow Cross-cutting Cascading actions Loops or chained agents multiply one error Execution budgets, depth and rate limits A circuit breaker halts dependent tasks ASI08
Prevent, Detect, Contain The table separates controls by timing for a reason. First, preventive controls reject an action before it runs. Meanwhile, detective controls notice odd behavior while it runs, and containment controls stop further actions so the damage stays small.
Still, detection on its own is weak protection. An alert that fires after a bulk export finishes only documents the breach. So every high-impact path needs a preventive or containment control first, with detection as the backup.
Why Enforcement Lives Outside the Model A model’s plan is a request, not an authorization. Of course, a system prompt that forbids customer exports helps, but an injected instruction can argue its way past it. Real enforcement therefore sits in trusted services between the agent and your systems, where a denied call stays denied however the agent rephrases it.
Agents that drift off script are therefore an engineering problem as much as a policy one. Our piece on rogue AI shows what happens when no external check exists at all.
The Defense-in-Depth Stack for AI Agents Defense in depth means no single control has to be perfect. If prompt-level defenses miss an injection, the tool gateway catches the out-of-scope call. And if the gateway is misconfigured, egress rules still stop the data from leaving. Six layers cover the five attack surfaces between them.
Layer 1: Context and Input Boundaries Treat everything the agent reads from outside as data, never as instructions. So tag retrieved content with its source and trust level, and keep it in its own part of the prompt. Then make sure it can never change which actions are allowed. Also apply access checks before sensitive records enter the context window, because anything in context can leak. That rule alone would have stopped the opening incident early.
Data classification makes this enforceable, since labels give the rules something to act on.
When records carry sensitivity labels, the retrieval layer can drop or mask restricted fields before the agent ever sees them. Kanerika’s Susan agent handles one part of that job by redacting PII from documents before they are shared. For the wider picture, see our guide to data security in AI .
Layer 2: Identity and Task-Scoped Permissions First, give each agent its own identity instead of a shared service account. Then scope its credentials to the task in hand, with short lifetimes, read and write rights split, and admin rights removed entirely. A zero trust stance fits well here, since every call is verified on its own merits.
After that, the test is simple. If the agent were fully compromised right now, what could it reach? The answer should be the data and actions of the current task, and nothing more.
Layer 3: The Tool Gateway Next, route every tool call through a gateway the agent cannot bypass. The gateway holds an allowlist of approved tools and operations, validates arguments and destinations, and applies rate limits per action type. It also pins tool definitions, so an MCP server that changes a tool’s description gets blocked rather than trusted.
Guardrails live at this layer too, as input, output and action checks the gateway enforces. Our guide to AI guardrails covers how to design and test them. MCP’s own security best practices add protocol issues such as the confused deputy problem and token passthrough.
Layer 4: Memory Controls Start by separating short-lived task context from durable memory. Only approved workflows should write to long-term memory, and each entry should carry its source, owner and expiry. Then isolate memory by user, tenant and data sensitivity, so one customer’s conversation can never shape another customer’s answer.
One rule matters more than the rest. Content in memory can inform a decision, but it can never authorize an action.
Layer 5: Delegation and Inter-Agent Limits Define which agents may talk to which, and what each may ask for. Likewise, requests between agents should be structured messages with an explicit task and a list of allowed actions, never free text. A sub-agent inherits at most the permissions of its task, and delegation depth gets a hard cap.
Also validate results on the way back. A sub-agent’s output is untrusted input for its parent, exactly like a web page.
Layer 6: Sandboxing, Egress and Budgets Finally, code-capable agents run in isolated sandboxes with no default network access. Outbound traffic also goes only to allowlisted destinations, which is the control that would have ended the opening incident at step six. Time, action and spend budgets stop runaway loops, while a circuit breaker cancels a workflow and its delegated children at once.
Watch on YouTube
How KANGuard Secures Your Data | Prevent Leaks & Unauthorized Access with DLP Policies
A walkthrough of how Kanerika’s kanGuard service applies DLP policies to stop data leaks and unauthorized access, the data-side backstop behind an agent’s egress limits.
On top of these limits, keep irreversible operations out of unattended execution altogether. Deleting datasets, paying invoices and changing access rights belong behind an approval step, which the runtime section below treats in detail.
MCP’s guidance on server-side request forgery shows what an egress rule looks like in practice. For OAuth-related fetches, it tells MCP clients to block private ranges such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. It adds link-local 169.254.0.0/16, which includes cloud metadata endpoints, and suggests an egress proxy such as Smokescreen for server-side clients.
Reference Deployment: Securing an Enterprise Analytics Agent Controls are easier to reason about when you can see them in one request path, so here is one. Take an analytics agent that answers revenue questions over data in Microsoft Fabric, Databricks or Snowflake, a pattern close to Kanerika’s Karl data insights agent . In total, the deployment has six parts, and each has one job.
Business user or application. Sends an authenticated request, and the user’s identity travels with it.Agent orchestrator. Plans the steps and picks tools, but holds no credentials of its own.Security enforcement gateway. Checks task scope, tool rights, arguments and destinations, then routes approvals.Data and tools. Governed tables, approved APIs and MCP servers, reachable only through the gateway.Controlled memory. Task state and stored context, written only through approved paths.Monitoring and approval services. Watch every component, pause or stop unsafe actions and hold high-impact steps for a human.How a Request Moves Through the Controls A sales director asks for revenue by customer for the last quarter. The orchestrator plans a query.
Then the gateway confirms that the director’s role can see those tables and that the query stays inside its limits. The agent then returns an aggregate summary without friction.
The database identity behind that query is read-only. OWASP’s Excessive Agency entry gives the pattern: an agent making product recommendations needs read access to a products table and nothing else. Here that means SELECT on the approved revenue tables, with no insert, update or delete rights, enforced by the database itself.
Later, the agent proposes exporting customer-level records to a spreadsheet for follow-up. The gateway classifies that as a sensitive data movement and holds it for approval. In the meantime, the aggregate analysis the director asked for carries on untouched.
The platform that hosts these pieces is its own design problem. Runtimes, queues and secret stores are covered in our guide to AI agent infrastructure . For Fabric-native builds, see how teams approach agentic AI applications in Microsoft Fabric .
Fail Closed When a Control Is Down Decide in advance what happens when a security dependency fails, because it eventually will. If the authorization service, monitoring or the approval queue is unreachable, sensitive actions are denied and dependent workflows pause until it returns. Also test that no connector lets the agent skip the gateway, since one side door cancels every control above.
Runtime Enforcement, Monitoring and Approval Design Runtime controls are where agentic AI security turns from a diagram into a series of decisions. Three questions shape them. Where do you check, what do you watch for, and when does a human step in?
Where to Check: Every Action Cycle A single check when a task starts cannot cover a plan that changes halfway through. So enforcement runs at every action the agent attempts. That means before it reads restricted data, calls a tool, runs code, writes memory, delegates work or sends anything out.
Authorization is checked again whenever a task changes scope or resumes after an approval. A permission granted at step one says nothing about step seven.
MCP’s security best practices show what re-checking looks like at the protocol level. An agent’s token starts with a minimal scope, such as mcp:tools-basic, that covers only low-risk discovery and reads. The first privileged call triggers a targeted WWW-Authenticate scope challenge, and the server logs each elevation with a correlation ID.
Signals Worth Alerting On Good monitoring looks for behavior that does not fit the task, so these signals deserve an alert in most deployments.
Calls to tools or destinations outside the approved set Sudden jumps in data read or export volume Repeated denied actions, which often mean an agent is probing its limits Memory writes from unexpected sources Agent-to-agent traffic on routes nobody approved Loops, recursive delegation or unusually high action rates Changes to a tool’s definition or capabilities after approval Then feed these into the same security operations tooling that watches the rest of the estate. Our post on AI agent observability covers the tracing that makes these signals possible in the first place.
Which Actions Need a Human Approval gates work best when they are saved for real impact, because reviewer attention is limited. Reviewers who are asked too often start clicking yes without reading. The matrix below ties each action type to a default decision, based on impact, reversibility and scope.
Table 2: AI Agent Runtime Approval Matrix
Agent action Default decision Control that makes it safe Read approved business data Allow Read-only scope and query limits Run approved analytical queries Allow within bounds Cost, row and time limits Update a few reversible records Allow with checks Scope validation and rollback Change many records at once Require approval Reviewer sees the exact proposed changes Export sensitive data Approve or deny Destination and data-scope checks Delete production data Block by default Separate approval path and a recovery plan Call an unknown external tool Deny Approved tool registry Delegate work outside the original task Deny Delegation boundary checks
Three of the eight rows default to allow, and that is deliberate. When reviewers only see the rare, risky requests, they actually read them, so the approval step keeps its value.
Binding an Approval to One Action An approval is permission for one specific action, never a blank check. To decide well, the reviewer should see the proposed action, the records it touches and the expected effect. That approval then binds to those exact parameters and expires after a short window.
If the destination, scope or parameters change, the agent therefore has to ask again. Expiry, rejection and an unavailable approval service all mean the same thing, which is that the action does not run.
Containment When an Agent Crosses a Line When an agent breaks a runtime rule, the first response is simply to block that action. Repeated violations then suspend the workflow, stop delegated tasks and cut further data access or outbound traffic. The agent resumes only after someone clears the cause and revalidates its scope.
Regulated sectors feel this most, for obvious reasons. In banking, an agent that pauses a payment for review costs a few minutes, while one that cannot be stopped risks a reportable incident. Our look at agentic AI in banking shows where those lines usually fall.
What the Five Eyes, OWASP and AWS Guidance Agree On Public guidance on agent security has firmed up fast. On May 1, 2026, CISA and the NSA joined agencies from Australia, Canada, New Zealand and the UK to publish joint guidance on agentic AI . Its title is Careful Adoption of Agentic AI Services. As Crowell’s summary notes, it names an expanded attack surface, compromised privilege, scope creep and misaligned behavior as core risks.
Unsurprisingly, its recommendations read much like the stack above, with least-privilege access, rigorous monitoring, phased deployment and mandatory human approval for high-risk actions. OWASP’s Agentic AI Threats and Mitigations work supplies the threat vocabulary, and the Top 10 turns it into a list teams can test against.
AWS also adds a handy sizing tool. Its Agentic AI Security Scoping Matrix sorts systems into four scopes, from no agency to full agency, and raises the control bar at each step. Placing each agent on that scale tells you how much of this guide you need today.
AI Assessment
How Ready Are Your Agents for Production?
Score your data, governance and security readiness in a few minutes with Kanerika’s AI maturity assessment. Then see which agent autonomy levels you can support safely today.
Start Your AI Assessment → Policy ownership, accountability and review boards belong to agentic AI governance , the companion discipline to the controls described here. Security builds the brakes, while governance decides who may drive and where.
Agentic AI Security Hardening Checklist, in Priority Order Not every control has to land on day one, though. The order below puts irreversible damage first, then multi-step risk, then coverage at scale.
Priority 0: Before Any Agent Gets Write Access Inventory every production agent, its tools and every system it can reach. Remove write, delete and admin rights the task does not need. Enforce authorization at every sensitive tool call, outside the model. Block unapproved external destinations and bulk exports. Run code execution and risky tools in isolated sandboxes. Require approval for high-impact or irreversible actions. Build a kill switch that suspends an agent and its workflows at once. Deny sensitive actions whenever an enforcement service is down. Teams that clear this tier can put an agent in front of real data without betting the business on prompt wording. Everything after it reduces risk further, but this tier is the floor.
Priority 1: State and Multi-Step Workflows Restrict long-term memory writes to approved sources and workflows. Isolate memory across users, tenants and tasks. Give every delegated task explicit boundaries and allowed actions. Cap chained actions, delegation depth and run time. Limit agent-to-agent traffic to approved routes. Alert on tool definition or capability changes. Suspend agents automatically after repeated blocked actions. Priority 2: Production Coverage at Scale Apply one tool policy across every agent runtime and framework. Detect abnormal patterns across multi-agent workflows, beyond single calls. Pin third-party agent tools and dependencies to reviewed versions. Close alternate execution paths that skip the gateway. Define recovery steps for interrupted or half-finished workflows. Then test each tier before it goes live. LLM red teaming shows whether the controls hold under attack. Meanwhile, AI agent evaluation checks that they do not break the agent’s real work.
Checklist
Enterprise Agentic AI Checklist
A practical checklist for taking agents from pilot to production, covering readiness, permissions, oversight and governance steps to confirm before agents act on real systems.
Get the Checklist → How Kanerika Secures AI Agents for Production Kanerika builds and runs AI agents for enterprises on Microsoft Fabric, Databricks and Snowflake. So our security work starts from each agent’s real execution path rather than a generic checklist. A typical agentic AI services engagement runs in three stages, and each one leaves the client with something it keeps.
Stage 1: Map Actions to Security Boundaries First, we trace how each agent retrieves data, calls tools and triggers business actions across the client’s platforms and applications. Every action then gets a decision of allow, approve or block. The result is a threat-to-control map like Table 1, written for that client’s systems.
Stage 2: Put Enforcement Between Agents and Systems Next come task-scoped permissions, a tool gateway, memory isolation and delegation limits, plus approval checkpoints for sensitive operations. Data protection starts below the agent. Sensitivity labels decide what can reach the context window at all, and Susan redacts PII from documents before they are shared.
Stage 3: Run, Monitor and Extend Finally, runtime signals flow into the client’s monitoring stack, with blocking and suspension rules tested before go-live. As agents gain tools and data sources, coverage grows with them under the AI governance model agreed with the client.
Classification is where many agent projects stall, because an agent can only respect a sensitivity label that exists.
For instance, one global bank kept its data across SAP, Dynamics 365, core banking systems and a central lakehouse. Kanerika used Microsoft Purview there to discover and classify personal data, including PII, PCI and PHI. As a result, classification accuracy rose by 72%, with zero data breaches and full compliance adherence, as the Purview banking case study describes.
Case Study
Zero Breaches, 100% Compliance for a Bank With Purview
Kanerika used Microsoft Purview to discover and classify PII, PCI and PHI across a global bank’s systems and lakehouse. Classification accuracy improved by 72%, with zero data breaches.
Read the Case Study → Kanerika’s own operations are certified to ISO 27001 and ISO 27701:2019, with SOC 2 Type II compliance. Our CISO, Lalit Rawat, explains his view on prompt injection in the video near the top of this guide. Pair that with data governance on the platforms underneath, and agent security stops being a bolt-on.
Wrapping Up Agentic AI security comes down to one discipline. Every action an agent takes must be checked, outside the model, against the task it was given.
So build the threat model around tools, memory, identity, delegation and inter-agent trust. Then put a control at each surface, starting with the ones that stop irreversible damage.
The finance agent from the opening did not need a smarter model. It needed a gateway that asked whether exporting the vendor master fit a ticket-triage task, and an egress rule that said no.
Frequently Asked Questions
What is agentic AI security? Agentic AI security is the practice of protecting autonomous AI agents and the systems they touch from being steered into harmful actions. It covers the tools an agent can call, its memory, the identity it runs under, the work it delegates and the messages it accepts from other agents, with controls that run outside the model itself.
How is agentic AI security different from generative AI security? Generative AI security focuses on what a model says, such as harmful output, data leakage in answers and prompt abuse. Agentic AI security adds what the system does. Agents call tools, change records, store memory and hand work to other agents, so the controls must check each action against the task before it runs.
What are the biggest security risks of AI agents? The main risks are prompt injection that hijacks the agent’s goal, misuse of tools, excessive permissions, memory poisoning, unsafe delegation between agents and data exfiltration. The OWASP Top 10 for Agentic Applications covers most of these, along with unexpected code execution, cascading failures, supply chain issues and over-trust by human reviewers.
How do you secure AI agents in an enterprise? Start with a threat model of tools, memory, identity, delegation and inter-agent trust. Give each agent its own identity and task-scoped credentials, route tool calls through a gateway, control memory writes, limit delegation, sandbox code and restrict outbound traffic. Then add runtime monitoring and human approval for high-impact actions such as bulk changes or exports.
Can prompt injection make an AI agent take unauthorized actions? Yes. Instructions hidden in a document, email or web page can enter the agent’s context and change its plan, which NIST describes as agent hijacking. The agent may then call tools or send data the user never asked for. Checking every tool call against the original task, outside the model, stops most of these actions.
How do you secure AI agents connected to MCP servers? Allow only approved MCP servers, pin each tool’s definition and block changes made after approval. Route calls through a gateway that validates arguments and destinations, and use scoped credentials instead of passing user tokens through. The MCP specification also says clients must treat tool annotations as untrusted unless they come from trusted servers.
What is memory poisoning in agentic AI? Memory poisoning happens when false facts or planted instructions get saved into an agent’s long-term memory or retrieval store. Later tasks then read that content and act on it, even after the original source is gone. Restricting who can write to memory, tagging entries with their source and isolating memory per tenant reduce the risk.
How do you secure communication between multiple AI agents? Define which agents may talk to each other and what each may request. Use authenticated, structured messages that name the task and the allowed actions instead of free text. Cap delegation depth, make sure a sub-agent never gains wider permissions than its task, and treat every result returned by another agent as untrusted input.
When should an AI agent require human approval? Require approval for actions with high impact or low reversibility, such as changing many records, exporting sensitive data, deleting production data or moving money. Routine reads and bounded queries can run automatically. Each approval should cover one specific action with fixed parameters, expire quickly and be requested again if the scope or destination changes.
Does zero trust apply to AI agents? Yes, and it fits agents well. Under zero trust, every request is verified on its own merits rather than trusted because of where it comes from. For agents, that means checking each tool call, data request and delegation against the current task and identity, even when the request comes from another internal agent.
Can traditional cybersecurity tools protect AI agents? Partly. Network controls, endpoint protection, identity management and logging still matter and catch many problems. What they miss is intent, since an agent’s malicious action often uses valid credentials and permitted APIs. Agent-specific controls such as task-scoped authorization, tool gateways and action-level approvals fill that gap.
How do you stop an AI agent that is taking unauthorized actions? Block the action at the gateway first. If violations repeat, suspend the workflow, cancel delegated tasks and cut the agent’s data access and outbound traffic. A tested kill switch should do this in one step. Resume only after the cause is found and the agent’s scope and permissions have been revalidated.
What is the minimum security stack before deploying AI agents? Before an agent gets write access, it needs its own scoped identity, authorization checks on every sensitive tool call, blocked external destinations, sandboxed code execution, human approval for irreversible actions and a working kill switch. Sensitive actions should also be denied automatically whenever an enforcement service is unavailable.
