A practical framework for evaluating agent platforms without becoming the person who said yes to the next supply chain breach.

Last November, a Fortune 500 retailer discovered that an AI coding assistant had been quietly exfiltrating source code to an attacker-controlled endpoint for three weeks. The entry point wasn’t a sophisticated zero-day. It was a community-contributed “skill” that a developer had installed to speed up their workflow. No one reviewed it. No one sandboxed it. No one logged what it did.

That incident, combined with the fallout from CVE-2026-25253 earlier this year, has put security leaders in a tough spot. Engineering teams want AI agents yesterday. The business wants the productivity gains. And you, the person whose name is on the approval, are supposed to figure out whether these things are safe.

Here’s the part nobody mentions: most AI agent platforms shipping today were not built for enterprises. They were built for indie developers who wanted to ship fast, and the security model reflects it.

Why Most CISOs Are Quietly Blocking Agents

Walk into any enterprise security review and you’ll hear the same concerns repeated. Plaintext credentials sitting in environment variables. Community skill marketplaces with zero vetting. Agents that can spawn subprocesses with no containment. Action logs that exist as unstructured text files somewhere on a container filesystem, assuming they exist at all.

The OpenClaw ecosystem is a useful case study. The framework itself has 230,000 GitHub stars and genuine technical merit. But the default deployment pattern, a Docker container with API keys mounted as environment variables and skills pulled from an unverified registry, is the kind of architecture that makes auditors visibly wince.

CVE-2026-25253 made this concrete. The vulnerability let a malicious skill escape its execution context and read credentials from the parent agent process. Any organization running OpenClaw with default configurations was exposed. The fix required manual patching across every deployed agent.

That’s the problem in miniature. Not that AI agents are inherently unsafe, but that the tooling has outpaced the security controls.

The Five Questions That Actually Matter

Before you approve any agent platform for enterprise use, your evaluation should answer five specific questions. These are the questions auditors will ask you later.

First, how are credentials handled at runtime? Second, how are skills or tools vetted before they reach production? Third, what actions can the agent take without human approval? Fourth, what evidence exists of every action the agent took? Fifth, what happens when something goes wrong?

Everything else is detail. Let’s walk through each.

Credential Handling: The Five-Minute Rule

Most agent platforms treat credentials as static configuration. You drop your API keys into a YAML file or a secrets manager, the agent loads them at startup, and they live in memory for the entire lifetime of the process. If that process is compromised, so are your keys.

This is backwards for how agents actually work. An agent doesn’t need your Salesforce token for eight hours straight. It needs it for the ninety seconds it takes to pull a record.

Look for platforms that implement secrets auto-purge with 5-minute TTL, where credentials are loaded for the task and then automatically wiped from agent memory. This pattern, sometimes called ephemeral credential injection, is how modern zero-trust architectures handle service-to-service authentication. Applying it to agent runtimes is overdue.

If the platform you’re evaluating keeps credentials resident in agent memory for the session duration, that’s a hard conversation with the vendor. Ask them specifically what happens to a long-lived OAuth token if the agent process is compromised at hour seven.

Skill Vetting Is Not Optional

The second question is about the extension model. Every useful agent platform has some way to add capabilities beyond the base install. Call them skills, tools, plugins, or functions. The name doesn’t matter. The review process does.

A 2025 report from the Open Worldwide Application Security Project found that 61% of AI agent skill marketplaces had zero automated scanning for malicious code, prompt injection attempts, or data exfiltration patterns. Most of them operate on a trust model closer to early npm than to enterprise software procurement.

Any platform you approve should have a documented skill verification process that includes code review, exfiltration analysis, and prompt injection testing. Ideally, that process is performed before publication rather than after user reports. Self-hosted frameworks like Hermes give you full control but push the vetting work onto your own team. Hosted platforms should be doing it for you, and you should see the documentation to prove it.

If the vendor tells you their skill marketplace is “community-moderated,” ask what that means in practice. If the answer is “users can report bad skills,” you have your answer.

Approval Workflows for Consequential Actions

Here’s where most evaluations go off the rails. Engineering teams focus on what the agent can do. Security teams need to focus on what the agent can do without asking first.

Draft an email? Probably fine. Send an email to an external recipient? Different category entirely. Modify a production database record? That should not be possible without explicit human approval, and the approval flow itself should be auditable.

The useful mental model is the one used in privileged access management. Group actions into tiers based on blast radius and reversibility. Tier one actions execute freely. Tier two actions require a human approval click with the full action context surfaced. Tier three actions require multi-party approval or are disabled entirely in production environments.

Any platform that doesn’t support this tiering, or that treats “human in the loop” as a suggestion rather than an enforceable policy, is not ready for enterprise deployment.

The Audit Log Test

Now for the question that separates serious platforms from hobby projects. When your auditor asks for evidence of every action an agent took in Q3, can you produce it?

The answer should be an exportable, tamper-evident log with timestamps, action types, inputs, outputs, credentials used, and the user or system that initiated each action. Not application logs. Not Slack message history. Actual structured audit logs that your SIEM can ingest.

This is where a lot of managed agent hosting options fall short. Many treat logging as a developer convenience feature rather than a compliance artifact. If the export format is “screenshot of the dashboard,” you do not have audit logs.

For a concrete example of what this looks like in practice, review BetterClaw’s enterprise security model. The architectural pattern they document, with sandboxed execution, encrypted credential handling, and structured action logs, is a reasonable baseline for what enterprise-grade agent infrastructure should include. Other approaches exist. Self-hosting on your own infrastructure with DigitalOcean or AWS gives you maximum control if your team has the capacity. Platforms like xCloud occupy a middle ground. The specific vendor matters less than the controls.

Incident Response for Agents

The last question is about what happens when something goes wrong, because something will go wrong.

If an agent starts behaving anomalously, whether because of a prompt injection, a compromised credential, or a legitimate bug, how quickly can you stop it? Can you stop a single agent without stopping all of them? Can you revoke credentials mid-task? Do you have health monitoring that will auto-pause an agent showing anomalous behavior, or does someone have to notice manually?

These are not hypothetical questions. The 2025 ClawHavoc incidents, where attackers used prompt injection to trick agents into exfiltrating data, demonstrated that detection and containment time matters as much as prevention.

Build this into your approval checklist. If the platform cannot show you a credible incident response story, the rest of the security model does not matter.

What Approval Actually Looks Like

Putting this together, here is the shape of a defensible approval decision.

You have documented answers to the five questions above. You have run a proof of concept that tested the credential handling, the skill vetting, the approval workflows, and the audit log export. You have the vendor’s SOC 2 report, or you have a compensating control plan if they don’t have one yet. You have an incident response runbook specific to agent compromise, not just generic cloud incident response.

And critically, you have a clear scope for the initial deployment. No agent platform should be approved for unlimited use on day one. Start with read-only actions against non-production data. Expand based on evidence, not enthusiasm.

The Question Behind the Question

The CISOs I talk to who have successfully approved AI agents in their organizations share one trait. They stopped treating agent approval as a binary yes-or-no decision and started treating it as a progressive trust problem.

You are not deciding whether AI agents are safe. You are deciding which controls need to be in place at which stage of deployment, and what evidence you need to move from one stage to the next. That reframing changes everything. It moves the conversation from “block or approve” to “what would I need to see to expand this.”

The agent platforms that will win in the enterprise are the ones that make that conversation easy. The ones that lose will be the ones still shipping plaintext credentials in 2027.