Trusting agents with enterprise data

Enterprises want what agents can do and cannot accept what agents might do. Resolving that tension is an architecture problem, not a model problem, and it became my problem as the founding engineer on an agentic data platform.

The question that shaped the design: when an autonomous agent runs against a customer’s operational data, what may it touch, on whose authority, and how does a human stay in control without becoming the bottleneck?

The answers became the platform’s execution model. Agents run inside isolated, per-project workspaces, never against shared infrastructure, so the blast radius of any action is bounded before the action exists. Every tool an agent can call is governed: access is authenticated end to end and authorized per session, so an agent acting for a user can do exactly what that user could do, and everything it does is attributable. Sensitive operations stop at human-in-the-loop permission gates. Long-running sessions are recoverable by design: a dropped connection resumes mid-conversation instead of discarding the work.

Two design positions did the heavy lifting. First, trust is a property of the substrate, not the agent: we assume the model will eventually do something wrong, and make wrongness cheap. Second, observability is not a feature, it is the product: an enterprise that can audit what an agent did will deploy it, and one that cannot, will not.

The result is the part of the platform I am most often asked about, and the part that turns security review from an obstacle into a sales asset.