You will not stop every prompt injection. Anyone who tells you otherwise is selling a story, not a control.
Agents read untrusted text all day: tickets, logs, web pages, vendor emails, tool output. One poisoned line can change what the model tries to do next. That is not a theoretical edge case. It is the default operating condition.
So the design question is not “how do we make the model ignore bad instructions forever.” The design question is: when the agent is compromised, what can it still touch, and can you prove what it tried?
Shared responsibility, said plainly
Security questionnaires keep asking who is responsible. The honest answer has layers.
Where secrets live. If an API key sits in the agent process environment, a compromised agent can read it. If the key is brokered at the gateway for a single allowed request, the agent never holds the long-lived secret. That split is not marketing. It is the difference between “the agent had the keys” and “the agent asked, and the gate decided.”
Who can see them. Operators, the control plane, and the runtime path that injects credentials for an allowed call. Not every child agent. Not every tool subprocess. Not a model context dump if you designed the broker correctly.
What happens on breach of the agent. Containment means the blast radius is the policy you wrote, not the whole cloud account. Egress that is not on the allow list fails closed. Credentials that were never in the environment cannot be exfiltrated from the environment. The denial is an audit event, not a silent drop you discover from a partner ticket.
Topology matters.
- Local CLI on your laptop: you own the machine, the daemon, and the policy files. AgentPaaS protects you from the agent. It does not protect you from you, or from malware already on the host.
- Managed cloud on the default carrier path: the platform runs the sandbox, the gateway, and the audit chain. You still own allow lists, secret binding, and what you ask the agent to do.
- Paid or customer Kubernetes: shared ops. Who patches the node, who holds cluster-admin, who can read etcd or volume snapshots: that is part of the enforcer story. If you cannot answer who enforces the enforcer, you do not have a finished design.
Shared responsibility is not a shrug. It is a map of which layer fails closed when the model goes wrong.
Containment, not prevention
Prompt injection is input. You do not “solve” input any more than you solve phishing by asking people to read carefully.
What you can do:
- Assume the agent may follow the wrong instruction.
- Give it the least power that still does the job.
- Enforce that power outside the agent’s code.
- Record every attempt that matters.
That is containment. AgentPaaS is built for that frame. Isolated containers. Internal-only networking. Default-deny egress at a gateway. Credentials injected per allowed request, not baked into the image. Tamper-evident audit with lineage.
We do not claim the model cannot be manipulated. We claim a manipulated agent should not become a free walk across your data plane.
If a vendor says “prompt-injection protection” the way a firewall vendor once said “unhackable,” treat it as a claim to test, not a control to trust.
What the public frameworks already tell you
You do not need a new religion. You need to put agents inside the security model you already run.
CISA and Five Eyes careful-adoption guidance for agentic AI lands on the same practical moves security teams already know: do not grant broad access because the demo looked good, start with low-risk tasks, and keep agents inside identity, logging, and network policy instead of beside them.
OWASP’s agentic top ten is the agent-shaped list: tool misuse, privilege abuse, identity gaps, supply chain, excessive agency. Use it. Do not wait for a perfect scorecard. Map each item to a runtime control you can show in a demo and in a log.
The older LLM lists still matter for model and app risks. They are not a substitute for runtime enforcement when the agent can call tools and open sockets.
Identity: agents are not in your IAM tree
Most IAM was built for people and long-lived services. Agents are neither. A single user action can fan out into child runs with different tools and different blast radius.
If your answer to “which principal did this?” is a shared service account on a fat role, you will fail the review that matters.
What CISOs actually need:
- Per-run identity so a child cannot silently inherit the parent’s entire world.
- Brokered credentials so the agent requests a capability and the gateway decides.
- Policy that is not prompt text. Prompts are advice. Gateways are enforcement.
- Audit that survives argument. Hash-chained, attributable, tied to the run that tried the call.
You will not see every agent in the corporate IAM console like a human hire. That is fine if the runtime is the place where identity and authorization actually happen. It is not fine if the runtime is a thin wrapper over a cloud role with *.
The four controls, in order
Same story as the product pages, because the story does not change when the URL is /blog/.
- Isolated container - non-root, constrained filesystem, no casual shell.
- Default-deny egress - destinations declared before the run, not negotiated after compromise.
- Gateway-brokered credentials - secrets are not a souvenir in
env. - Tamper-evident audit - allow and deny both leave a record with lineage.
Order matters. Isolation without egress control is a polite jail. Egress control with keys in the jail is a locked door and an open window. Audit without the first three is a diary of the breach.
What “good” looks like in an incident
Without runtime enforcement: the child posts to an unknown host, the key was in the environment, and you learn from the notification.
With enforcement: the destination is not allowed, the credential was never present, and you page on the deny line.
That is the product bar. Not a perfect model. A contained failure.
Edit this page when the truth moves
This post is markdown in git. When a control changes, update the file, bump lastmod, rebuild, redeploy. Do not leave a pretty static lie on the apex because a CMS felt heavier than the truth.
If you are reviewing AgentPaaS: assume injection succeeds. Ask what the exploit can still do. Ask who holds the keys. Ask who enforces the enforcer. Ask for the deny in the audit log.
That is the standard we build to.