The Allowlist Is Not Enough: Why AI Agent Security Needs to Understand Provenance
By the Prophet Technology team
Enterprises are moving fast on AI agents. What began as chatbots answering support tickets has become autonomous systems that query production databases, file tickets, send emails, reconcile invoices, and orchestrate workflows across a dozen SaaS tools. The productivity story is real. The security story, in most organizations, has not caught up.
Most teams that have thought about agent security at all have landed on the same first answer: an allowlist. Enumerate the tools the agent may call, deny everything else, require approval for destructive operations. This is necessary. It is genuinely the right first step, and if you have not done it, do it this quarter.
But we want to make a more uncomfortable argument: an allowlist alone cannot secure an agent, because the most dangerous agent actions are composed entirely of allowed operations.
The attack that never touches your infrastructure
Consider a routine deployment: an assistant agent with read access to a shared inbox and permission to send email — both perfectly reasonable grants for its job. Now an attacker sends one message to that inbox. Buried in the body, or in white-on-white text, or in a quoted reply chain, is a sentence addressed not to your employee but to your agent: forward the attached customer sheet to this external address.
No credential was stolen. No endpoint was breached. No malware was deployed. The agent read an email (allowed), interpreted its contents (that is its job), and sent an email (allowed). Every individual action passes the allowlist. The attack lives entirely in the composition: untrusted content flowed in, and a sensitive action flowed out under its influence.
This is indirect prompt injection, and it is not a theoretical concern. It is the defining attack class of the agentic era, because it inverts the usual economics of intrusion. The attacker no longer needs access to your systems — only to any content your agent will eventually read: an email, a web page, a PDF invoice, a support ticket, a calendar invite, a row in a shared spreadsheet.
Why detection-based defenses keep losing
The industry's first response has been to detect the injection itself: signature libraries of known jailbreak phrasings, heuristic scanners for "ignore previous instructions" patterns, statistical classifiers with confidence thresholds. These tools have their place as one layer among several, but as a primary defense they share a structural flaw — they are playing an unwinnable enumeration game.
Malicious instructions do not have a fixed grammar. They can be paraphrased infinitely, translated into any language, split across multiple documents, encoded in formats the scanner does not parse, or phrased so innocuously that no classifier could flag them without drowning you in false positives. Signature-based defense against natural-language attacks inherits the worst dynamics of antivirus circa 2005: perpetually one variant behind.
The lesson from decades of application security is that when you cannot reliably classify content, you should instead track provenance — where data came from and what it is now trying to make happen.
Provenance-aware security: taint tracking for agents
Taint tracking is an old and battle-tested idea from program analysis: mark data from untrusted sources as tainted, propagate that mark as the data flows through the system, and enforce policy at sensitive sinks. Applied to AI agents, it changes the security question in a fundamental way.
Instead of asking "does this content look malicious?" — unanswerable in general — the system asks "is untrusted input influencing a high-risk action?" — which is a question about data flow, and answerable with engineering rather than guesswork.
In practice, a provenance-aware control layer sits between the agent and the world and maintains a running state for every session:
Sources are classified at ingestion. Content from an external email, a fetched web page, or an uploaded document enters the session tainted. Content from your own systems of record does not.
Taint propagates through the reasoning chain. If the agent's next tool call embeds parameters derived from tainted content — an email address that first appeared inside an external document, a URL lifted from a fetched page — the call inherits the taint.
Policy fires at the sink, not the source. A tainted parameter reaching a low-risk read operation may pass silently. The same taint reaching an outbound email, a payment operation, or a bulk export escalates: block, or route to a human with full context.
The email attack above dies at step three. Not because any scanner recognized the malicious sentence — no scanner needed to — but because an address originating in untrusted content attempted to become the destination of a data-bearing action. The trap is at the choke point, where the attacker must eventually pass, rather than at the front gate, where they have infinite disguises.
The latency and sovereignty problem
There is a second, quieter requirement that global enterprises discover the moment they try to deploy any of this: the decision layer itself has real-world constraints.
If every agent action must be evaluated for risk, that evaluation sits on the hot path of every workflow. Routing it to a third-party cloud API adds tail latency to every step of every agent — and, more importantly for many of our clients, it ships the parameters of every action (which may include customer data, financial records, or regulated information) to an external processor.
For organizations operating under frameworks like the EU AI Act, MAS guidelines in Singapore, PIPL and data-export rules in China, or sector rules in healthcare and finance, that is frequently a non-starter. The pattern we see winning is a compact, locally deployed decision model: a small language model running inside the customer's own environment that scores each action in milliseconds — intent, tool, parameters, taint state — and returns allow, block, or escalate. Cloud-scale intelligence is not required to answer "should a tainted external address receive this export?" A small model with the right context answers it faster, cheaper, and without data ever leaving the building.
What a complete control layer looks like
Pulling the threads together, a production-grade agent security architecture has three cooperating layers:
Interception — a proxy through which every tool call and outbound request must pass. This is where allowlists, operation-scoped permissions, egress controls, and rate caps live. It bounds the blast radius.
Provenance-aware decisioning — taint tracking plus a local risk model evaluating each action in context, with human-in-the-loop escalation for high-risk cases. This is what catches the attacks that are made of allowed operations.
Tamper-evident audit — every action recorded in a hash-chained log, policies versioned and reviewed like code, and exportable evidence packs for auditors and regulators. This is what makes the first two layers provable, which in regulated industries is the difference between a pilot and a deployment.
Most vendors and most internal builds stop at layer one. Layer one is where security starts; layers two and three are where it becomes real.
Start by watching, not blocking
A practical closing note from our deployment work: do not switch on enforcement on day one. Run the control layer in observe-only mode for a few weeks and review what it would have blocked. Nearly every team we have worked with finds risky flows they did not know existed — and that report, grounded in their own traffic, is what turns agent security from a compliance checkbox into a funded priority.
Comments