.png)
Across enterprise environments Opsin Labs studied for the 2026 State of Agentic Adoption report, 67% of agents were built by employees with no engineering background and 60% run with allow-all access. The reflex when those numbers reach a security team is to write a policy and schedule a training. Someone in finance attaching a tool to an agent on a Tuesday afternoon will not rank ten security principles against a workflow they need working by Friday. They need one decision they can make in thirty seconds.
Building secure AI agents comes down to controlling three conditions that are only dangerous in combination:
An agent holding all three can be steered by the text it reads into taking an action it was already permitted to take, which is what turns a prompt injection into a data leak. Break any one of the three and the same injection has nowhere to go. A large language model does not reliably distinguish instructions from the content it was asked to process, because everything arrives as tokens in the same context window. Agents must not be allowed to hold all three at once.
An AI agent is a system that can plan a sequence of steps and call tools to carry them out without a human approving each one. That autonomy is the value, and it is what changes the risk calculus: a human with excessive access has to choose to misuse it, while an agent with excessive access will exercise it the moment the right text lands in its context. Prompt injection is the delivery mechanism, meaning instructions hidden inside content the agent treats as data, whether an inbound email, a shared document, a web page, or an uploaded file. An injection only becomes an incident when it meets permissions broad enough to satisfy it.
Consider a research agent that reads arbitrary web pages, holds customer PII in its context, and can send external email. Each capability is defensible in isolation, added one at a time for good reasons, and no individual permission grant looks wrong in a review. Together they mean a single poisoned page can exfiltrate customer data. The same applies when an agent hands work to another agent, since delegation multiplies reach, so the trifecta has to be evaluated across the chain rather than agent by agent.
Start with purpose, because every scoping decision downstream depends on it. Write one or two sentences in the agent's description that accurately capture what it does, and treat a description that sprawls as a signal the agent is trying to do too much. "Helps our IT support team look up and summarize open incident tickets and draft response notes for review. It does not close or delete tickets." That gives you the audience, the topic, the actions, and the limit in one line, plus something to measure later behavior against.
Then scope the data to the topic. Connect the agent to the smallest set of documents its purpose requires, and prefer a curated source over a broad connector. Broad connectors inherit whatever is over-shared or mislabeled in the underlying files, so an agent can surface a sensitive document nobody realized was reachable. A sales-enablement agent pointed at a shared drive that also holds medical records and executive pay files has a data problem no amount of careful prompting will fix.
Then match actions to risk. Reading and summarizing are low risk, drafting and scheduling are medium, and sending externally, changing or deleting records, running code, and calling outside URLs are high. Draft by default, with a human committing anything that leaves the company, changes an official record, or cannot be undone. A meeting assistant that drafts a follow-up for the user to send is a different security object than one that can silently create forwarding rules and send externally. Watch code execution and outbound network calls in particular, since those two convert an injection into an incident more reliably than anything else.
Because instructions are guidance the model usually follows, not a wall it cannot cross. Rules in an agent's system prompt are worth writing so they can be tested ("never email anyone outside @ourcompany.com" beats "be careful with sensitive data"), but a determined injection can cause an agent to bypass its own rules. The right assumption is the one security teams already make about breach: the agent will be fooled at some point, so design for the moment it is.
That means backing every rule that matters with an enforced limit, whether that is declining to connect the risky tool, keeping the sensitive data out of reach, or requiring human approval before the action runs. Opsin Labs found agents whose prompts explicitly restricted them to read-only use while the underlying tool connection still carried full server-operation access, a rule describing an intention with nothing behind it.
Identity is where this gets missed most often. Credentials and API keys never belong in an agent's instructions or tool descriptions, because anything written there sits in the model's context on every run, gets copied into logs, and can be pulled back out by an injection that asks the agent to repeat its own configuration. Secrets belong in a vault, fetched as short-lived tokens by the code performing the action. Each tool should also authenticate as the user interacting with the agent rather than as its owner, since owner-level authentication means every user inherits the owner's reach, which is how a team lookup tool quietly becomes an entitlements bypass.
Use the trifecta as a triage filter. Agents that hold private data, read untrusted input, and can act externally are the ones worth reviewing this week, and in most environments that set is small enough to work through by hand. Ownership is the second filter: Opsin Labs found 35% of enterprise agents orphaned, still running and still holding full access with nobody accountable for them.
The third filter is drift, and it resists a point-in-time review. An agent correctly scoped in March accumulates a tool in May and a data source in July, and the gap between what it was built to do and what it is doing widens without anyone deciding it should. Catching that requires connecting three things most security stacks keep separate: the identity an agent authenticates as, the data its tools can reach, and its behavior once live compared with its stated intent. That connection is what a dynamic contextual layer provides, and it lets a team remediate at the owner and the configuration instead of triaging alerts with no root cause attached.
The trifecta is a fast route to conclusions the published frameworks already support, and each leg has a named risk behind it:
Agent interactions in these environments grew 14x over the study period, and the builders driving that growth will not slow down for a review queue. The teams staying ahead of it make the trifecta a design question at creation time rather than a discovery exercise afterward. So the question for your next agent review is narrow enough to answer today: which of your agents can read something an attacker controls, reach something you would not want published, and send it somewhere outside?
Start with a one or two sentence purpose statement in the agent's description, then scope everything else to it. Connect the smallest set of data sources the topic requires, grant the least powerful tool that does the job (read instead of write, drafting instead of auto-send), and share the agent with the smallest audience that genuinely needs it.
The single highest-value check is whether the agent holds all three of the following at once: access to private data, exposure to untrusted input, and the ability to act or send externally. If it does, remove one before it goes live.
The lethal trifecta, named by security researcher Simon Willison in June 2025, describes the combination of private data access, exposure to untrusted content, and external communication capability. Each is safe alone.
Together they mean an attacker who can get text in front of the agent, through a web page, an inbound email, or an uploaded file, can direct it to retrieve sensitive data and send that data out, using permissions the agent legitimately holds.
No. Instructions in a system prompt are guidance the model usually follows, and a determined prompt injection can cause an agent to bypass its own rules. Written rules are a useful first layer, particularly when written so they can be tested, but every rule that matters needs an enforced limit behind it: do not connect the risky tool, keep the sensitive data out of reach, or require a human to approve the action.
In a secrets vault, fetched as short-lived tokens by the code that performs the action, never in the agent's instructions, system prompt, or tool descriptions. Anything written into those fields sits in the model's context on every run, tends to be copied into logs and traces, and can be disclosed by a prompt injection that asks the agent to repeat its own configuration. Each connected tool should also authenticate as the user interacting with the agent rather than as the agent's owner, otherwise every user of that agent inherits owner-level reach.
The untrusted-input leg is LLM01 Prompt Injection and the permission leg is LLM06 Excessive Agency in the OWASP Top 10 for LLM Applications 2025. In the OWASP Top 10 for Agentic Applications, published by the OWASP GenAI Security Project in December 2025, injected content redirecting an agent maps to ASI01 Agent Goal Hijack, a connected tool turned into a weapon maps to ASI02 Tool Misuse & Exploitation and ASI05 Unexpected Code Execution, inherited credentials map to ASI03 Identity & Privilege Abuse, and orphaned agents map to ASI10 Rogue Agents.
Across enterprise environments Opsin Labs studied for the 2026 State of Agentic Adoption report, 67% of agents were built by employees with no engineering background and 60% run with allow-all access. The reflex when those numbers reach a security team is to write a policy and schedule a training. Someone in finance attaching a tool to an agent on a Tuesday afternoon will not rank ten security principles against a workflow they need working by Friday. They need one decision they can make in thirty seconds.
Building secure AI agents comes down to controlling three conditions that are only dangerous in combination:
An agent holding all three can be steered by the text it reads into taking an action it was already permitted to take, which is what turns a prompt injection into a data leak. Break any one of the three and the same injection has nowhere to go. A large language model does not reliably distinguish instructions from the content it was asked to process, because everything arrives as tokens in the same context window. Agents must not be allowed to hold all three at once.
An AI agent is a system that can plan a sequence of steps and call tools to carry them out without a human approving each one. That autonomy is the value, and it is what changes the risk calculus: a human with excessive access has to choose to misuse it, while an agent with excessive access will exercise it the moment the right text lands in its context. Prompt injection is the delivery mechanism, meaning instructions hidden inside content the agent treats as data, whether an inbound email, a shared document, a web page, or an uploaded file. An injection only becomes an incident when it meets permissions broad enough to satisfy it.
Consider a research agent that reads arbitrary web pages, holds customer PII in its context, and can send external email. Each capability is defensible in isolation, added one at a time for good reasons, and no individual permission grant looks wrong in a review. Together they mean a single poisoned page can exfiltrate customer data. The same applies when an agent hands work to another agent, since delegation multiplies reach, so the trifecta has to be evaluated across the chain rather than agent by agent.
Start with purpose, because every scoping decision downstream depends on it. Write one or two sentences in the agent's description that accurately capture what it does, and treat a description that sprawls as a signal the agent is trying to do too much. "Helps our IT support team look up and summarize open incident tickets and draft response notes for review. It does not close or delete tickets." That gives you the audience, the topic, the actions, and the limit in one line, plus something to measure later behavior against.
Then scope the data to the topic. Connect the agent to the smallest set of documents its purpose requires, and prefer a curated source over a broad connector. Broad connectors inherit whatever is over-shared or mislabeled in the underlying files, so an agent can surface a sensitive document nobody realized was reachable. A sales-enablement agent pointed at a shared drive that also holds medical records and executive pay files has a data problem no amount of careful prompting will fix.
Then match actions to risk. Reading and summarizing are low risk, drafting and scheduling are medium, and sending externally, changing or deleting records, running code, and calling outside URLs are high. Draft by default, with a human committing anything that leaves the company, changes an official record, or cannot be undone. A meeting assistant that drafts a follow-up for the user to send is a different security object than one that can silently create forwarding rules and send externally. Watch code execution and outbound network calls in particular, since those two convert an injection into an incident more reliably than anything else.
Because instructions are guidance the model usually follows, not a wall it cannot cross. Rules in an agent's system prompt are worth writing so they can be tested ("never email anyone outside @ourcompany.com" beats "be careful with sensitive data"), but a determined injection can cause an agent to bypass its own rules. The right assumption is the one security teams already make about breach: the agent will be fooled at some point, so design for the moment it is.
That means backing every rule that matters with an enforced limit, whether that is declining to connect the risky tool, keeping the sensitive data out of reach, or requiring human approval before the action runs. Opsin Labs found agents whose prompts explicitly restricted them to read-only use while the underlying tool connection still carried full server-operation access, a rule describing an intention with nothing behind it.
Identity is where this gets missed most often. Credentials and API keys never belong in an agent's instructions or tool descriptions, because anything written there sits in the model's context on every run, gets copied into logs, and can be pulled back out by an injection that asks the agent to repeat its own configuration. Secrets belong in a vault, fetched as short-lived tokens by the code performing the action. Each tool should also authenticate as the user interacting with the agent rather than as its owner, since owner-level authentication means every user inherits the owner's reach, which is how a team lookup tool quietly becomes an entitlements bypass.
Use the trifecta as a triage filter. Agents that hold private data, read untrusted input, and can act externally are the ones worth reviewing this week, and in most environments that set is small enough to work through by hand. Ownership is the second filter: Opsin Labs found 35% of enterprise agents orphaned, still running and still holding full access with nobody accountable for them.
The third filter is drift, and it resists a point-in-time review. An agent correctly scoped in March accumulates a tool in May and a data source in July, and the gap between what it was built to do and what it is doing widens without anyone deciding it should. Catching that requires connecting three things most security stacks keep separate: the identity an agent authenticates as, the data its tools can reach, and its behavior once live compared with its stated intent. That connection is what a dynamic contextual layer provides, and it lets a team remediate at the owner and the configuration instead of triaging alerts with no root cause attached.
The trifecta is a fast route to conclusions the published frameworks already support, and each leg has a named risk behind it:
Agent interactions in these environments grew 14x over the study period, and the builders driving that growth will not slow down for a review queue. The teams staying ahead of it make the trifecta a design question at creation time rather than a discovery exercise afterward. So the question for your next agent review is narrow enough to answer today: which of your agents can read something an attacker controls, reach something you would not want published, and send it somewhere outside?
