A Control Plane Gives Enterprises Enforceable Limits When AI Prompt Injection Gets Through

The first wave of enterprise AI was mostly conversational. A model took a prompt, returned text, and the worst a bad answer could do was mislead someone. That era is closing fast. Agents now hold credentials, reach into production databases, call tools, move money, and run code, which turns a manipulated instruction from a wrong answer into a real action. The security questions that follow are different in kind: what each agent is allowed to touch, how its decisions get logged, and whether anyone can even say what's running in production. The answer taking shape is a control plane, a layered set of controls keyed to what a given agent can actually do, built on a foundation most organizations skip, which is knowing what they have.

Emmanuel Dahunsi spent several years at Goldman Sachs, most recently as an Executive Director and Security Architect for AI and Tech Risk, where he designed the controls and reference architecture behind the firm's AI and cloud platforms. Earlier, at JPMorgan Chase, he worked on the risk side of the bank's move to public cloud. His work lives at a delicate seam, translating what engineers actually build into language auditors and regulators can act on, and that vantage point shapes how he reads the current moment.

"Your prompt-injection guardrails are just theater. They fail in production," Dahunsi said. Guardrails aren't useless, but prompt injection can't be fully solved. It's non-deterministic, and as models take on audio and images, the avenues for smuggling in a malicious instruction keep multiplying. The practical goal becomes containing what an agent can do once an injection slips through, rather than chasing perfect prevention. That containment is what the control plane provides, and the foundation under it is governance.

• Inventory comes first: Natural-language tooling and low-code platforms let almost anyone stand up an agent, wire it to a production database, and leave it running without IT ever logging it. Industry surveys keep surfacing the same pattern: inside large enterprises, agents are proliferating the way ungoverned cloud instances did a decade ago, faster than anyone is tracking them. "If you ask any CISO or CTO for an authoritative count of how many agents are live in production, most of them can't give you one. That's just the reality." He recommends phasing the cleanup rather than trying to fix everything at once, moving static API keys into a vault with rotation first, then issuing short-lived tokens scoped to each agent, and working toward verifiable workload identities as the end state.

• Autonomy versus agency: "Agency is probably the bigger problem. Without tools, an agent is just a chatbot," Dahunsi said. The two get conflated, but they pull in different directions. Autonomy is how much freedom an agent has to make its own decisions; agency is the set of tools that let it act, from running code to moving funds. A highly autonomous agent boxed into a narrow sandbox stays relatively safe, while a low-autonomy agent handed broad tools can still do real damage, which is why the tooling deserves the closer look. An orchestration layer is the natural spot to set how much latitude each agent gets, enforced through intent, human checkpoints, and ongoing monitoring instead of static access rules.

• Least privilege on tools: The discipline that follows is least privilege, applied to capability rather than data access. OWASP's agentic guidance makes the same case, treating an agent's toolset as the first thing to pare back. There are two common ways to enforce it, and each carries a cost. "You can have a central policy enforcement point, kind of like an agent gateway. The downside is that if that gateway is compromised, the attacker has lateral access to your whole environment." The alternative, pushing enforcement out to a sidecar beside each agent, trades that single point of failure for more surface to maintain.

Deciding what an agent may touch is only half the job. The other half is the machinery that watches it do so and can step in when something goes wrong, and that machinery is where governance stops being a document and becomes enforceable. Borrowing from patterns security teams already use, the controls stack up around the agent the way a zero-trust architecture stacks up around a user, turning oversight into architecture instead of leaving it on paper. The highest-value controls, in roughly the order Dahunsi prioritizes them, begin with identity.

• Identity and a trail: Every agent gets a unique, short-lived cryptographic identity, which keeps a stolen key from being useful for more than a narrow window and stops agents from sharing the ambient credentials developers tend to leave lying around. It's the same logic pushing enterprises to treat agents as non-human identities with their own lifecycle. On top of identity sits observability. "You want to know which user delegated this permission to what agent, and what it did with it," Dahunsi said, "what tools it called, where it pulled its context from, what action it took and when." That record is also what regulators are starting to require, with the EU AI Act's record-keeping rules pressing for exactly this kind of traceability over a system's life.

• The deterministic backstop: Non-deterministic guardrails belong in the stack as one layer of defense, but the control that actually holds is a deterministic policy sitting outside the model. Whatever ends up in an agent's context, a hard rule can require human approval for any transaction over a set dollar amount, or block it outright. An egress proxy matters just as much, inspecting traffic at the application layer so sensitive data can't be funneled out through a domain that happens to be allow-listed. One caution on rollout: these controls go into production watching before they go into production blocking. "If you start by blocking, you get a flood of false positives, and then someone's calling you at midnight because they can't get any work done," Dahunsi said. The way out is to measure what a guardrail actually catches against benchmarks you run yourself before you let it enforce.

• A bill of materials: Prompt injection gets the headlines, but among agent risks, supply chain may draw the least attention relative to the damage it can do, and it reaches well beyond the model. Procedural memory, the reusable skills an agent loads to carry out a task, often comes straight from public repositories with nobody scanning it, the way unvetted container images once spread through infrastructure. The answer borrows directly from software security: a machine-readable bill of materials issued for every agent. "For every agent you should have a bill of materials: what models it uses, what MCP servers it connects to, what tools, what memory." Tied back to the registry, that profile is what separates an agent that holds up in production from one that stalls once the demo is over.

None of this holds without the organization behind it. In Dahunsi's experience, the limiting factor is usually organizational: legacy identity systems, inherited technical debt, and business units racing to ship all pull against careful control, and no architecture survives that pressure unless leadership stands visibly behind it. Get that backing, and the payoff is concrete, an executive who can sit across from an auditor, pull up any agent by its card, and show its owner, its identity, where it runs, what it's built from, and every action it has taken.

"This has to come from the top. The CIO, the CTO and the CISO have to be the ones saying that every agent in production gets governed, leading from the front," Dahunsi said.