Governance

Can you stop it in 60 seconds?

Every AI committee eventually asks two questions that matter more than any benchmark: can you show me exactly what the agent did, and can you stop it before it does something worse — say, before it sends another 5,000 emails. We build the answer into the agent layer from day one, structured around seven controls we call IADTHAM.

I — IdentityA — AuthorizationD — Data controlT — Tool controlH — Human in the loopA — AuditabilityM — Monitoring
The framework

Seven controls, one question each.

I / Identity

"Whose agent did that, exactly?"

In production, "the AI did it" isn't an answer — it's a shrug. Every Fulcrum agent runs under its own identity: a scoped service principal, not a shared API key buried in an environment variable. Every action traces back to a specific agent, session, and run, the same way you'd expect from any employee's login.

A / Authorization

"Could it have done something worse?"

An agent's permissions are never broader than the role it's standing in for. We map agents into the partner's existing RBAC and identity provider — Entra ID, Okta, whatever's already there — rather than issuing a parallel set of god-mode credentials. If a human in that role couldn't touch it, the agent can't either.

D / Data control

"What could it actually read or write?"

Default posture is read-only. Every write path is a named, reviewed exception — a specific tool, against a specific system, with a specific scope. "The agent has database access" is not a sentence that should ever be true in a Fulcrum deployment.

T / Tool control

"What is it even capable of doing?"

Agents don't improvise capabilities. Every tool available to an agent is enumerated, versioned, and reviewed before it ships — adding a new one is a reviewed change, not something the model decided to try. If you can't list what an agent can do, you can't govern it.

H / Human in the loop

"Who has to say yes first?"

Some actions are always gated: irreversible ones, high-blast-radius ones, anything touching money or an external party at scale. We define those approval points and escalation paths before launch, as part of the build — not after the first near-miss forces the conversation.

A / Auditability

"Can you recreate exactly what it did last Thursday?"

Every model turn and tool call is logged as a structured, timestamped trace — inputs, outputs, and the reasoning path between them. Reconstructing a specific agent run from a specific day is a query against the trace store, not an incident-response fire drill.

M / Monitoring

"Can you stop it in the next 60 seconds?"

We instrument drift — latency shift, refusal-rate change, tool-call failure rate — so problems surface before someone notices the output looks wrong. Every deployment ships with a kill switch at three levels — one asset, one channel or system, or the whole agent — that a named owner can trigger without waiting on us. Sixty seconds, no vendor call required, before it sends the other 4,987 emails.

Why this comes up earlier now

Governance isn't the last slide anymore.

A few years ago, governance was the compliance appendix — something you addressed after the pilot worked, if legal asked. That order is reversed now. The AI committee, the security review, or the operator who remembers a vendor incident from last year asks the kill-switch question and the audit-trail question before they ask about the model. Treating IADTHAM as an afterthought means re-architecting under pressure, mid-pitch, in front of the people who control the yes.

We build every engagement against these seven controls from the Phase 0 diagnostic forward — not as a separate governance workstream bolted on before launch. See how that fits into the rest of the build on the Capabilities page.

Ask us these two questions.

"Show me what the agent did last Thursday" and "stop it right now" are the fastest way to find out whether an AI vendor's governance is real or a slide.