An AI agent can choose its own actions at runtime. Give it a real credential and an open network, and a prompt injection or model error can become a record change, a data disclosure, or a security incident that is hard to reconstruct.
I started AgentPaaS for the gap between useful agents and the controls security teams need before those agents receive production authority. AgentPaaS is a runtime for agents, applications, MCP servers, and agentic workflows. You build and evaluate the agent where you work today, then run it under controls that limit what a compromised agent can reach.
Watch the founder overview
The security problem is specific. An agent may read a ticket, log, email, or web page that contains hostile instructions. It may follow those instructions, call a tool, or send a request that its author never intended. If the agent can read a reusable secret, the request can carry that secret with it. If the network is open, the destination may be anywhere.
The model may be wrong. The runtime still has to enforce the boundary.
Four controls contain the blast radius
AgentPaaS applies four controls in this order. They work at the runtime boundary where an agent’s decisions become external effects.
Isolated container
The agent runs in an isolated container with a non-root process, a read-only root filesystem, no shell, dropped capabilities, and seccomp. The container is a boundary around the agent process. It does not claim to be a kernel 0-day sandbox.
Default-deny egress
The agent has no direct route to the internet. Outbound HTTP and HTTPS traffic goes through a gateway. A signed policy declares the destinations the run may reach. An undeclared destination is denied. Raw TCP, UDP, and ICMP are outside the current transparent proxy model.
Gateway-brokered credentials
The agent uses a credential through an approved request path. The secret value stays in the credential store and outside the agent process. The gateway applies it when the request leaves. Audit records identify the credential by its label or ID, never by its value.
Tamper-evident audit
Allowed and denied actions enter a hash-chained audit trail with signed checkpoints. Records include the run, decision, destination, credential use, and request lineage. Verification can detect changes to the chain. Post-export deletion of the final records needs an external anchor to detect, so audit integrity has limits too.
These controls give a security team something better than a model instruction to behave. The agent can still produce an unsafe answer or try an unsafe action. The runtime can deny a destination, keep a reusable credential outside the agent, and record the decision for review.
Read How enforcement works for the request path and the difference between local enforcement, the default Cloud tier, and the paid high-assurance tier.
Build locally, then run the same governed package
The path from an idea to a governed run has six steps:
- Build and evaluate locally. Use Hermes or your own environment. Test ordinary inputs and edge cases. Check that the agent stays within its task and does not receive raw credentials.
- Pack with AgentPaaS. Package the agent with its policy and publisher identity. Declare the destinations and credential labels it needs.
- Push the signed package to Cloud. The cloud component registry admits the package and records its build identity.
- Deploy the component. A deployment creates the live execution target with its policy and secret bindings.
- Invoke the agent. Run the deployment directly, or use it as a component in a workflow.
- Inspect the run. Runs and Logs expose execution records, gateway decisions, and audit evidence.
A single agent does not need a workflow. Use a workflow when a task needs multiple agents or tools. Build the components locally, then compose and run them under the same policy model. Child work does not quietly receive broader authority than its parent.
The guided weather demo walks through this path. It shows a local agent, a denied request after removing a host from policy, and the same governed package running in AgentPaaS Cloud.
What AgentPaaS does not claim
AgentPaaS contains blast radius. It does not prevent prompt injection. A manipulated model can still produce a harmful or incorrect action inside the boundary.
You still own application authorization, data classification, approval rules for high-impact actions, dependency review, destination review, credential scope, and incident response. AgentPaaS does not establish that an agent’s answer is true. It does not replace application output validation.
The assurance also depends on where the run happens. Local mode uses an internal-only network and a gateway sidecar, and it trusts the developer’s machine. The default Cloud tier enforces egress at the boundary through AgentPaaS control-plane code. It does not claim substrate-enforced isolation. The paid high-assurance tier, available on request, uses a dedicated Kubernetes namespace with kernel-enforced network policy.
The threat model records these boundaries, including the current HTTP and HTTPS scope and the fact that AgentPaaS is working toward SOC 2 and is not yet certified. Read AgentPaaS runtime security for agents for a deeper threat scenario, and our OWASP 2026 coverage map for a risk-by-risk account of what the runtime covers and what remains yours.
Try the controls yourself
We are live today, and the first test should be practical. Start a Free 30-day trial. No card required. Try the guided weather demo and inspect the denial and audit records.
If you want the local runtime and CLI, the open-source repository is AgentPaaS on GitHub. The what is AgentPaaS page explains the product path in more detail.
Do not take the security claims on trust. Declare one destination, attempt another, inspect the denial, and verify that the credential value never entered the agent. That is a better product evaluation than a slide deck.