Once a team accepts container isolation, default-deny egress, and credential brokering, a second objection usually follows: “Signed bundles and audit trails do not play such a huge part if we are running these workflows in the cloud.”
The intuition makes sense until you ask two questions. Is the thing running the thing you approved? What did it do while nobody was watching?
Cloud infrastructure answers neither question for you. It gives more people and systems a path to deploy, runs workloads without a human beside them, and places shared control planes between you and the code.
Runtime controls cover the present tense
Runtime security controls describe what a workload can do right now. Isolation, egress policy, and credential brokering cover that present tense.
Signed bundles cover the past tense: is what is running the thing we approved? Tamper-evident audit covers the future tense: when something happens, can we prove what it did?
A platform that covers only the present tense gives you a runtime. Governance needs admission, runtime enforcement, and evidence.
A credential broker needs an admission control
Credential brokering has an easy-to-miss consequence. It turns deployment into a credential-delivery channel. Whatever gets to run can receive credentials.
In a cloud account, the deployers may include CI, developers with cloud access, the coding agent that wrote the workflow, and a stolen token belonging to any of them. Signed admission is the refusal point. The control plane can reject code that did not pass through the packaging pipeline, where secrets scanning runs fail-closed, an SBOM is captured, and policy is attached.
Isolation contains the actions of a workload. Signing limits which code becomes a workload in the first place. Without signed admission, a broker can hand production credentials to arbitrary code. These controls work together.
Code and policy drift apart
Egress enforcement acts on a policy document. Cloud execution does not prove that the enforced policy is the policy a reviewer saw, or that it is attached to the same code.
A signed lock binds the image digest, SBOM digest, and policy digest into one unit. Without that binding, the same agent can ship with a wider egress policy. Different code can ship under a familiar policy name. A hotfix can reach production after its review has gone stale.
The lock answers a plain question: is what is running still what we approved?
The signed SBOM also gives you a direct answer on CVE day. When a dependency vulnerability appears, you can identify running agents that contain the dependency without asking each workload to report on itself.
Cloud logs do not prove what an agent did
Cloud platforms provide logs. The operator who controls the platform can often mutate them, and the records usually lack workload meaning. A useful audit event says which agent, under which policy digest, called which domain with which credential lease during which run.
There is another gap. Egress policy separates allowed destinations from denied destinations. It cannot tell whether an allowed destination was used for the right purpose.
When Replit’s agent deleted a production database, it misused a system it was allowed to touch. When EchoLeak exfiltrated data through a trusted Teams domain, destination checks could remain green. [1] [2]
Agents run unattended and at machine speed. The audit trail records the allowed action that turned out to be wrong.
Tamper-evidence makes that record testable. A hash-chained record with signed checkpoints does not stop a powerful actor from rewriting history. It makes the rewrite detectable, and it lets someone verify the exported record offline. That is a different standard from accepting a vendor’s log viewer on trust.
Evidence protects both sides of a cloud dispute
A shared control plane creates a dispute a single laptop rarely has. A tenant suspects the platform leaked its data. The platform says the workload acted on its own. If both sides can quietly rewrite the record, the dispute goes to whoever has better lawyers.
A tamper-evident audit trail gives both sides the same evidence. It can expose platform misbehavior, and it can show that a workload made the action itself. Cloud creates this evidence problem. Cloud does not solve it automatically.
The case where you do not need governance
The objection is right for a solo developer running a throwaway agent locally, with no credentials, on a task whose output nobody relies on. That workload has little to govern.
The situation changes when a workload runs unattended, holds a credential, or answers to another human. Those are common properties of a cloud deployment.
The cloud provider owns infrastructure security. Someone still needs to govern the workload. Without a platform control, that ownership is undefined.
What signed admission and audit look like
AgentPaaS signs each package at build time. The signed bundle binds the image, SBOM, and policy digests into one verifiable lock. Admission can refuse unsigned or drifted workloads.
Each run emits a hash-chained audit record with signed checkpoints. The audit verify command checks exported evidence offline, without trusting the platform that produced it.
Isolation, default-deny egress, and brokered credentials describe the intended operating envelope. Signed admission and verifiable audit give you a way to check that the deployed workload and its actions match the record.
These controls have limits. Signed admission does not prove that the code is good. Egress policy does not distinguish good from bad use of an allowed destination. Tamper-evident audit makes changes detectable, though it cannot make an event impossible to dispute. Prompt injection remains a source of unsafe behavior. Runtime containment limits what follows from that behavior.
Read the Agent Security overview, the threat model, and the security review. For the companion argument, read Your Agent Workflows Are Not as Internal as You Think.
Free 30-day trial. No card required.
FAQ
Why do signed bundles matter if agents run in a secure cloud?
Cloud providers secure infrastructure. Anyone or anything that can deploy to the account can run code there, and a credential broker can deliver real credentials to that code. Signed admission limits execution to code that passed through the reviewed packaging path.
What is tamper-evident audit for AI agents?
It is a hash-chained record of workload actions with signed checkpoints. It does not prevent history from being altered. It makes alteration detectable and supports offline verification without trusting the platform that produced the record.
Are cloud provider logs enough for agent incident review?
Provider logs can be mutable and often lack workload semantics, such as the agent, policy version, credential lease, and run involved in an action. Incident review needs a record an auditor can verify independently.
Can egress policy stop an agent from misusing an allowed destination?
No. Egress policy distinguishes allowed from denied destinations. It does not judge whether an allowed destination was used correctly. A verifiable record of what the agent did covers that gap.
Sources
[1] https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ (in the wild) [2] https://aim.security/lp/aim-labs-echoleak-blogpost (disclosed vulnerability)