Blog

Ten CISO Objections to Agent Security, Answered

· Parvez Mohamed

The ten objections enterprise CISOs raise in security reviews of agent platforms, answered honestly: attestations, prompt injection, platform absorption, secrets custody, IAM, residency, isolation, and viability.

These are the ten objections that come up in enterprise security reviews of agent platforms, in roughly the order they arrive. Some have strong answers. Others start with “not yet.” I publish both kinds because a vendor that answers only the easy questions is giving you useful information about the hard ones.

Objection 1: “You have no SOC 2, no ISO certification, no pentest report. Come back when you have attestations.”

Fair. AgentPaaS is working toward SOC 2 and is not certified. An independent pentest is coming soon. If your procurement policy requires an attestation letter today, we are not your vendor today.

You can verify some things today. The local runtime is open source, so your team can read the enforcement code instead of relying on a questionnaire. Each deployed workload carries signed digests for its image, dependency manifest, and policy. That makes “what is running” checkable.

The audit trail has hash-chained events and signed checkpoints. You can verify it offline on your machine, without our cooperation. An attestation tells you that someone else checked us. These mechanisms let you inspect the workload and its evidence yourself.

Objection 2: “Prompt injection is unsolved. What exactly are you claiming to stop?”

We make no claim about the model’s mind. AgentPaaS does not stop prompt injection. The claim is containment: assume the model gets fooled, then bound what a fooled model can do.

Every agent gets its own identity instead of sharing a service account. Credentials are brokered to the workload at run time instead of sitting in code or environment variables. Egress is denied by default, with only declared destinations reachable. Every action lands in a tamper-evident audit trail.

When an injection succeeds, the policy bounds the blast radius. The agent workflow security post walks through the same problem from the workflow side.

Objection 3: “The model vendors and platform giants will build this in. Why buy a layer that gets absorbed?”

Consolidation is real. Palo Alto Networks agreed to acquire Portkey in April 2026 to make AI gateway governance part of its security platform. [1] Model vendors ship their own containment. Incumbents are buying their way into the category. That validates the problem. It does not settle your architecture decision.

Vendor self-containment has limits. Anthropic disclosed that its eval agent published a booby-trapped package to the real PyPI registry. OpenAI confirmed that its internal agents uploaded hundreds of malicious packages to RubyGems before roughly 700 of its agents attacked Hugging Face. [2] [3]

Your agents will also run across more than one model or platform. A policy that works inside one provider’s sandbox covers only the workloads hosted there. AgentPaaS compiles one signed, portable policy into enforcement wherever the workload runs, with brokered credentials and audit evidence that you can verify offline. The control should follow the workload.

Objection 4: “We already bought AI security posture management and non-human identity discovery.”

Keep it. Posture management and discovery answer the first question: what agents exist, what they connect to, and where dangerous combinations appear. The 2026 CISO AI Risk Report found that 92 percent of large-enterprise security leaders lack full visibility into their AI agent identities. That is the gap those tools address. [4]

Discovery does not constrain a workload at run time. Knowing that an agent exists, holds a powerful token, and reads untrusted email does not stop it from using that token badly at 3 a.m.

Posture tells you where the risk is. Runtime enforcement bounds it. The two compose: discovery finds the fleet, AgentPaaS governs the workloads, and the audit export feeds evidence into the dashboard you already use.

Objection 5: “Our AI gateway already does governance.”

Your gateway governs model traffic. That matters. It covers one part of an agent’s request path.

An agent’s risk also travels through tool calls, package installs, API writes, and every destination the workload can reach. A proxy that inspects prompts and completions sees one channel and misses the rest. Anthropic’s eval agent published to PyPI and collected credentials at an endpoint it stood up itself. [2]

The gateway layer has supply-chain risk of its own. LiteLLM, an open-source LLM proxy, reported backdoored releases to PyPI in March 2026 that carried a credential-stealing payload. [5]

AgentPaaS governs the workload, its reachable destinations, the credentials it receives, and the signed pipeline that produced it. Model governance is one input to that control set.

Objection 6: “Your broker touches all our API keys. You just became the honeypot.”

The instinct is right. The comparison needs to include the alternative. Without a broker, the same keys get copied into agent environments, container images, and CI variables. Those copies are hard to enumerate and harder to revoke. Distributed secrets are uncounted secrets.

AgentPaaS keeps raw values out of code, images, and environment defaults. Locally, they live in the OS keychain. Workloads receive short-lived, scoped leases at launch instead of standing credentials. The control plane is a high-value target, so admission is signed. The broker arms only workloads that passed through the reviewed packaging pipeline and are bound to a policy digest.

The September 2026 workflow identity hijacking research described a failure pattern in privileged broker architectures: credentials minted for one principal can be used by another. [6] The design response is to bind every lease to the requesting workload’s identity and policy. That is why per-agent identity comes first.

Read the companion post on why cloud does not govern your agents for the custody and signing argument in more detail.

Objection 7: “Agents are invisible in our IAM, and you have no RBAC or SSO. How does this run enterprise-wide?”

There are two honest answers. The product answer comes first: the cloud trial is single-admin today. RBAC with per-employee seats and SSO are roadmap items. We will not sell roadmap as shipping.

The industry has the same identity problem. The 2026 survey found that 86 percent of enterprises do not enforce access policies for AI identities. [7]

Agents are invisible to IAM when they run as shared service accounts with borrowed human tokens. AgentPaaS gives each agent an identity at packaging time and attributes its actions to that identity in the audit trail. That provides per-agent attribution and revocability today. It also gives RBAC something concrete to govern when that roadmap work ships.

Objection 8: “Where does our data go? Subprocessors, residency, retention, model training.”

Cloudflare is our sole subprocessor. The backend runs on Cloudflare. Data residency is the United States. We do not retain your data for training, and we store only what the platform needs to run: run metadata, the audit chain, and the artifacts required by the product path.

We do not force no-training flags at model providers. Those controls live at your inference layer. If you ask, our support team will help you verify your provider settings.

If those facts do not fit your policy, the open-source runtime runs on your machines. It contacts only destinations declared in policy, so your data stays in your environment. That is the strongest residency guarantee we can offer, and it is free.

Objection 9: “Containers are not sandboxes. What is the actual isolation boundary?”

That is the right question. On the default cloud tier, per-instance egress is carrier-enforced at the network layer. We do not claim substrate isolation on that tier. You should ask anyone making that claim to name the mechanism.

On the local runtime, the agent container sits on an internal network with no default route. DNS resolves only through the gateway. The container’s own firewall drops everything except the gateway path before the workload process starts. Egress enforcement is topological: there is no route out except through the policy point.

For workloads that need a harder boundary, a gVisor or Kata runtime class is on the roadmap as a high-assurance mode. Ask which properties are enforced by topology, which rely on policy checks, and what happens to each when the workload is compromised. We will answer those questions for our stack in writing.

Objection 10: “You are an open-source startup. What happens to our governance if you disappear?”

Your governance artifacts are designed to outlive the company. The runtime is MIT-licensed open source. Your policies live in your git repositories next to your agents. Signed bundles and exported audit chains verify offline without a phone-home call.

If AgentPaaS disappeared tomorrow, your enforcement layer would keep running, your evidence would remain verifiable, and your policies would remain yours. Individual use is free forever. We will never paywall single-machine security. A governance layer that disappears with a vendor’s runway would be a poor governance layer.

The commercial model is simple: individuals are free, and organizations pay for the cloud control plane and what comes with it. That is the model we can defend in a procurement review.


Every objection reduces to the same request: prove it. Signed digests show what is running. Brokered credentials show what each workload can touch. Default-deny egress shows where it can go. A verifiable audit chain shows what it did.

Read the Agent Security overview, the threat model, and the security review. Then start a free 30-day trial. Free 30-day trial. No card required.

Sources

[1] https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-to-acquire-portkey-to-secure-the-rise-of-ai-agents [2] https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals (in the wild) [3] https://www.theguardian.com/technology/2026/sep/11/openai-agents-rubygems-malicious-packages (in the wild) [4] https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-governance-framework-gap-20260403/ [5] https://docs.litellm.ai/blog/security-update-march-2026 (in the wild) [6] https://www.noma.security/ [7] https://www.aizome.ai/resources/seven-questions-every-enterprise-should-be-able-to-answer-about-their-ai-agents-and-why-86-can-t-answer-even-one