Three patterns we keep seeing in stalled enterprise agent rollouts

Over the last few months we've been talking to security and platform teams at half a dozen Fortune 500s with agents in pilot. Different industries, financial services, healthcare, retail, manufacturing. Different vendors, Anthropic, OpenAI, in-house. Different use cases, internal employee productivity, customer support, software engineering.

The blockers, when we ask carefully, are remarkably consistent. Three patterns keep coming up.

Pattern 1: "We can't tell which agent did what."

Every team has logging. Most have observability tools. None can answer this question with the precision their security organization requires: "for this specific action, which agent invocation, running which prompt, called by which user, was responsible?"

The reason is structural. Logs are produced by the systems being acted upon, not by the acting system, and they don't carry a verifiable identity for the agent. When five agents share the same service account API key, the receiving service has no way to disambiguate. When an internal LLM gateway proxies all model calls, the gateway's identity gets recorded, not the agent's.

For a single-tenant, single-agent system this is annoying. For a platform team running 200 agents across the company, it's a non-starter. SOC2 auditors are starting to flag it.

Pattern 2: "We can't prove the user actually authorized this."

The pilots that get the most traction are the ones where agents take real action: send the email, file the ticket, update the record, transfer the funds. The pilots that get killed in security review are exactly the same set.

The question security teams ask: "if this agent does something the user didn't intend, what's our defense?" Today the answer is some combination of "we have a log of the user clicking 'go'" and "the agent is supposed to follow its instructions." Neither survives contact with a serious incident.

What's needed is a chain of consent that survives an adversarial inspection. The user signed a delegation. The agent operated within it. The action fits the granted scope. Each step has a cryptographic signature. The audit isn't a forensics exercise; it's a verification.

Pattern 3: "We can't tell our regulators what happened."

This one is escalating fast. EU AI Act provisions on accountability and transparency for high-risk AI systems are biting. US state regulators are starting to ask about agent decisions in lending, hiring, and healthcare. SOC2 Type II reports are being asked to scope agentic workflows.

In every case, the regulator's question is functionally the same: show me, with evidence, what the agent did and why. Companies that can produce a signed, tamper-evident audit graph have an answer. Companies that can produce log files have a problem.

The common thread

None of these patterns are model problems. The models are smart enough. The frameworks are mature enough. What's missing is the trust infrastructure between agents and the systems they touch, the layer that lets a security team look at an agent action and verify, with math, what happened.

This is what we're building. The pieces have existed in adjacent fields for decades; the protocol that puts them together for the agent era hasn't existed yet. Read the v0.1 spec, or apply to be a design partner if any of these patterns are blocking you right now.