How Snowflake, FFF Enterprises, and Sysdig Are Building AI Governance That Doesn't Kill Innovation

Your AI governance committee is probably solving the wrong problem. The debate inside most enterprises right now is framed as a tradeoff: either you control agent capabilities tightly enough to satisfy security and compliance, or you move fast enough to stay competitive. Teams that believe this binary are building governance structures that will fail in both directions - either becoming bottlenecks that push agent deployments into shadow IT, or rubber-stamping approvals that leave production agents ungoverned.

The practitioners who have actually shipped agentic systems at scale - including security and AI leaders at Snowflake, FFF Enterprises, and Sysdig, speaking at the [un]prompted conference - are clear that this framing is wrong. Enterprise AI governance cannot be a binary gate. It has to be risk-based, continuous, and embedded in how engineering teams work, not imposed on top of them after the fact.

The Misconception: AI Governance Must Choose Between Control and Speed

Traditional IT governance was built for slow-moving infrastructure. Change control works when you are pushing a configuration update to a load balancer. Approval gates work when the thing being approved is a firewall rule that will sit static for months. That model does not translate to agentic systems, where the agent's behavior at runtime depends on tool availability, context, and inputs that governance committees cannot fully anticipate during a pre-deployment review.

The misconception persists because it is partially true for traditional software. Tighter controls on a static application really do reduce risk without much operational cost. But an agent is not a static application. Its behavior is emergent. A governance committee that reviews an agent's tool list at deployment time and approves the configuration is not governing the agent - it is governing a snapshot of the agent that will diverge from reality the moment the first user interacts with it.

In practice, this shows up in two failure patterns. The first: governance committees that require weeks of security review before any agent touches production data. Engineering teams route around them. The agents get deployed anyway, just without audit trails. The second: committees that approve agent deployments in bulk because the review process is too slow to be selective. Both outcomes leave the organization more exposed than a well-designed risk-based model would.

Where This Binary Breaks: Real Governance Failures in Production

Here is a failure mode we see repeatedly. A team builds an agent with two tools: a database query tool and a Slack notification tool. Governance reviews both tools in isolation. The database query tool has read-only access to a customer analytics table - approved. The Slack notification tool posts to an internal engineering channel - approved. The committee signs off.

What the committee did not model: the combination. The agent can query customer PII from the database and, under the right prompt conditions, surface that data in Slack. Neither tool alone is the problem. The tool-use chain is the problem. This is not a hypothetical - it is the category of risk that Ragini Ramalingam has described in the context of Snowflake's approach to AI governance: you cannot evaluate tools in isolation, you have to model what an agent can do with the combination of tools it has access to.

Billy Norwood at FFF Enterprises has articulated the same pattern from the operational side: governance that operates as a one-time gate before deployment misses the runtime behavior that actually creates risk. And Sergej Epp at Sysdig has pointed to the observability gap that results - if you only govern at the point of approval, you have no signal when an agent's behavior drifts from what the committee reviewed.

The operational cost of the binary is concrete. Teams facing strict governance delays find workarounds. Shadow AI deployments proliferate. The agents that do go through review get approved without meaningful scrutiny because the review process is a bottleneck, not a filter. Meanwhile, the teams that skip governance entirely accumulate technical and security debt that compounds as agent capabilities expand.

The Corrected Model: Risk-Based, Continuous, Committee-Driven Governance

The corrected belief is this: AI governance in enterprises is not an approval gate. It is a risk-based decision framework that runs in parallel with development, not upstream of it.

The architectural shift is from "governance approves or rejects" to "governance and engineering jointly model risk, define acceptable thresholds, and agree on monitoring requirements before deployment and throughout the agent's operational life." The committee's job is not to greenlight or block. It is to ensure that risk is understood, that mitigations are proportionate, and that monitoring is in place to detect when reality diverges from the model.

What Snowflake is doing in practice: AI governance that emphasizes transparency and auditability of agent decisions. This means agents produce logs that are legible to the governance function, not just to engineering. It means the committee can ask "what did this agent do last week" and get an answer. FFF Enterprises is running cross-functional governance committees with clear risk thresholds tied to data sensitivity and tool blast radius - not a single approval process but a tiered model where low-risk agents go through a lightweight review and high-risk agents get deeper scrutiny. Sysdig is instrumenting agent behavior at the tool-call level, treating anomalies in tool-use patterns as security signals the same way they treat anomalies in container behavior.

Practical Governance Patterns: How to Build Risk-Based Committees

The committee structure that works at Snowflake and FFF Enterprises is cross-functional: engineering, security, product, and someone from compliance or legal who understands what data the organization is actually regulated on. Four people is enough. The key design decision is that the committee does not vote to approve or reject. It produces a risk assessment with conditions.

Walk through a concrete scenario. A team proposes an agent with access to a customer database query tool and an email tool. The committee does not say yes or no. Instead, they ask: what queries can the database tool execute - predefined, parameterized queries only, or arbitrary SQL? What email addresses can the email tool reach - internal only, or any address? What is the blast radius if a prompt injection causes the agent to combine these tools unexpectedly? The team comes back with answers. The committee agrees on mitigations: parameterized queries only, email restricted to an internal domain allowlist, tool-call logging enabled with a 30-day review cadence.

The governance artifacts that make this repeatable: a threat model template adapted from STRIDE for agentic systems (Spoofing maps to prompt injection, Tampering maps to tool-call interception, Repudiation maps to missing audit logs, Information Disclosure maps to data exfiltration through tool parameters, Denial of Service maps to agent loops or runaway tool calls, Elevation of Privilege maps to capability escalation through tool chaining). A risk matrix that scores tool combinations by data sensitivity and blast radius. And a review schedule that is tied to the agent's risk tier, not a fixed calendar.

For teams that need to start somewhere, here is a copy-paste governance checklist:

[Tool name] | [Data accessed] | [Blast radius if compromised] | [Mitigations in place] | [Monitoring enabled] | [Committee approval date] | [Next review date]

Fill this in for every tool, not every agent. Then look at the tool combinations. That is where the real risk lives.

Capability-Based Access Control for Agents

Role-based access control fails for agents for a specific reason: RBAC governs identity, not behavior. An agent with a "database analyst" role can invoke any query tool available to that role. But governance wants to restrict not just which tools the agent can access, but what it can do with them - which tables, which columns, which query patterns.

The implementation pattern that addresses this: tool definitions include a capability token or allowlist that specifies what the agent is permitted to do. When the agent invokes a tool, the runtime checks the capability token against the request. A database query tool with a capability token scoped to read-only access on a specific table will reject a write operation even if the agent attempts it - and even if the underlying database credentials would technically permit it.

Anthropic's tool-use API supports capability-based patterns through tool definitions and input schema validation. You define what the tool accepts as input, and the API enforces that schema. Custom implementations extend this by adding server-side validation at the tool execution layer, so a prompt injection that tries to pass an out-of-schema parameter gets rejected before it reaches the underlying system.

In practice: an agent is deployed with capability tokens that allow it to read customer data but not modify it. A prompt injection attempts to trick the agent into running an UPDATE statement. The capability token does not include write permissions. The tool call fails at the runtime validation layer, not at the database level. The failure is logged. The governance committee sees it in their next review. This is the model - defense in depth that produces observable signals, not just silent blocks.

Observability and Anomaly Detection: What Signals Matter

Sysdig's approach to agentic observability treats tool calls the way container security tools treat syscalls: as a stream of behavior that can be baselined and monitored for deviation. The instrumentation captures agent ID, tool name, input parameters, output summary, timestamp, and the user context or upstream agent that triggered the call. That full context is what makes anomaly detection possible.

The signals that indicate tool misuse in production are consistent across the cases we have seen. Unusual query patterns: an agent that has spent three weeks querying an orders table suddenly queries a credentials table. Privilege escalation: an agent invokes a tool it has never called before, or calls a tool with parameters outside its established range. Tool chaining anomalies: an agent that normally runs one tool call per session starts chaining five in sequence, with outputs from each feeding into the next. Timing anomalies: tool calls that happen outside normal operating hours, or in bursts that do not match the agent's typical interaction pattern.

The detection scenario: monitoring detects that an agent is invoking a database query tool with parameters that have changed significantly from its baseline. The query is syntactically valid. The capability token permits it. But it is querying a table the agent has never accessed before, at 2am, in a session with no upstream user context. That combination of signals triggers an alert. The governance committee gets a notification. Engineering investigates. The root cause: a prompt injection in a document the agent processed earlier that afternoon, sitting in the agent's context window and activating hours later when the agent resumed work.

We do not yet have robust tooling that catches all of this automatically. Sysdig's AI workload security capabilities are advancing toward this, but the baseline-and-alert pattern still requires human judgment to configure and interpret. The signals are there; the tooling to act on them at scale is still maturing.

What You Should Be Doing Right Now

Start with an audit. Map every agent deployment in your organization - production, staging, and anything that has been running in a team's AWS account without formal review. Document which tools each agent has access to and what data those tools can reach. Do this in two weeks. Security and engineering own it jointly. If you discover deployments that nobody in security knew about, that is the finding. That is what you bring to leadership to justify the governance investment.

Next, stand up a committee. It does not need to be large. Engineering lead, security, product, and one compliance-adjacent person. Their first task is not to review existing agents - it is to agree on the risk matrix and the decision criteria. What makes an agent high-risk versus low-risk? What mitigations are required at each tier? How often does each tier get reviewed? This takes a few weeks of meetings. It is worth it.

Implement tool-call logging before you do anything else on the technical side. One week, engineering owns it. Every tool invocation logged with full context. No exceptions. You cannot detect anomalies without a baseline, and you cannot build a baseline without logs. If you are on a managed platform, use whatever logging hooks the platform exposes and supplement with application-layer logging at the tool execution boundary.

Then implement capability-based access control on your highest-risk tool combinations. Not everything at once - the agents with access to sensitive data and high-blast-radius tools first. Use the governance checklist to identify them. This is a two-to-four week engineering effort per agent, depending on complexity.

Finally, schedule your first red-team exercise within 90 days. Test prompt injection against your highest-risk agents. Test whether your capability tokens actually block out-of-scope requests. Test whether your logging captures the attack. The results of that exercise are your next governance committee agenda.

Snowflake, FFF Enterprises, and Sysdig are all iterating on this. None of them have declared the governance problem solved. The field is moving too fast and the threat landscape is shifting as agent capabilities expand. What they have is a model that runs continuously, produces observable signals, and improves over time - which is the only kind of governance that will hold up as agentic systems become more capable and more deeply embedded in production workflows.