Execution boundary · AI agents
Fulcrum sits on the execution boundary so policy, budget, and trust checks happen before a tool call lands — with reviewable evidence for supported verdicts.
DROP TABLE invoices;Policy checks
Live preview of routed-action evidence
The status quo
Agents can spend money, touch data, and mutate systems faster than any review queue can keep up. The only safe place to intervene is before the call lands.
Observability tells you what the agent already did. It does not stop the action on the hot path.
Teams keep rebuilding narrow policy checks around tools, budgets, and approvals — one risky surface at a time.
By the time someone reviews the trace, the data move, spend event, or destructive mutation has already landed.
How it works
LLM, planner, copilot
AgentFulcrum boundary
DB, payments, prod APIs
Tool / systemWrap the tool call at the boundary — SDK, proxy, or sidecar. No model lock-in.
Policy, budget ceilings, caller identity, and trust signals — all before the side effect.
Supported verdicts preserve reviewable, queryable evidence for supported flows.
Integration
SDK around the routed tool call, MCP proxy in front of governed MCP clients, or a localhost sidecar. Each supported path preserves reviewable evidence under the same policy set.
TypeScript SDK · drop-in around the risky tool call.
governed-refund.ts
import { FulcrumClient } from '@fulcrum-governance/sdk';
const client = new FulcrumClient({
host: 'api.fulcrumlayer.io:50051',
apiKey: process.env.FULCRUM_API_KEY,
onFailure: 'FAIL_CLOSED',
});
const envelope = client.envelope({
workflowId: 'invoice-refund-bot',
});
// Pre-execution check; verdict + reviewable decision evidence returned.
const allowed = await envelope.guard('stripe.refund', refundIntent);
if (allowed) {
await stripe.refunds.create(refundIntent);
envelope.log('refund_issued', { amount: refundIntent.amount });
}Evidence
Sample routed tool calls can be queryable, reviewable, and replayable where supported. Compliance, security, and on-call read the same artifact — no screenshots, no Slack threads.
Validation posture
The public landing should show real evidence, not placeholder enterprise packaging. These are the evidence surfaces the current repo and validation corpus can actually support.
A single cache-hit in-process policy path measured 0.009ms P99 in a controlled benchmark.
Fulcrum Boundary v0.11.0 ships DecisionRecordV2, verify-record, explain, replay, and policy-as-code tests for local fixtures.
Formal proof status starts with Fulcrum-Proofs theorem inventory and applies only to scoped governance invariants.
Checked-in validation artifacts record attack scenarios with explicit evidence paths and current caveats.
The MCP route is the current production Boundary route; other Boundary routes remain preview unless promoted by release truth.
Current public wording is limited to the promoted 1K to 1M token evidence, not broader 10M claims.
Initial rollout
The first win is one governed action surface with reviewable evidence, not a broad platform rollout. Validate the route behavior there, then expand deliberately.
Evaluation access
We use the first evaluation to scope the action your team wants governed before execution and determine whether Fulcrum is the right fit for that initial rollout.