Enforcement

Enforcement is the act of turning your governance.fms into a binding decision on every tool call. This page describes the pipeline in detail, what runs, in what order, and what guarantees each step provides.

If you haven't read How Faramesh works yet, do that first. It introduces the pipeline at a higher level and is much shorter. This page is the depth.

Quick recap

A tool call arrives at the daemon. Twelve numbered steps run. Steps 1–8 are pure functions over (policy AST, action payload) and produce the decision. Steps 9–12 happen only on permit and handle credential brokering, tool execution, and audit. Defer and deny stop at step 8.

The pipeline is deterministic: same input, same decision, every time. There is no LLM in the decision path.

A worked example before we go deep. The policy:

agent "support-bot" {
  default deny
  rules {
    permit stripe/refund if amount < $500
    defer  stripe/refund if amount >= $500
    deny   stripe/payouts
  }
  rate_limit "stripe/*": 10 per minute
  budget daily { max $500 on_exceed defer }
  redact stripe/refund args: ["card_number"]
}

A call: stripe/refund({"amount": 80, "card_number": "4242…"}).

Walking the pipeline:

1. Identity → resolved.
2. Rule match → first rule matches (permit stripe/refund if amount < $500).
3. Conditions → 80 < 500 is true.
4. Rate limit → bucket has tokens, ok.
5. Budget → daily $0 + this call ≤ $500, ok.
6. Egress → n/a (SDK tier).
7. Redaction → card_number will be masked in step 11.
8. Decision → PERMIT.
9. Provider broker → mint a Stripe key with 30s TTL.
10. Run tool → refund $80.
11. DPR → write hash-chained record (with redacted card_number).
12. Audit sink → emit to Splunk/Datadog/etc.

Every other tool call goes through the same twelve steps.

Modes

Two enforcement modes, set in runtime { mode = ... }:

faramesh status always shows the current mode. faramesh apply validates that production-critical providers (KMS, audit sink) are reachable before promoting from audit to enforce.

The pipeline

A single tool call traverses ten stages. Each stage can deny, defer, or pass.

rules {
  permit stripe/charge if amount < $500
  defer  stripe/refund
  deny   stripe/payouts
}

Latency budget

Steps 1–8 typically complete in 0.4–1.2 ms on a warm cache. Step 9 (provider call) is the slow path:

DPR signing happens out of band with batching, the call returns to the agent on permit immediately after step 9.

Failure modes

Faramesh fails closed. Every error path denies; nothing slips through because the daemon got confused.

What the policy can't do

To keep the engine deterministic, FPL conditions deliberately cannot:

• Call external services (no HTTP from policy).
• Read files or environment variables at evaluation time (env-resolution happens at compile, not at decision time).
• Invoke language models.
• Reach into the WAL.
• Modify rates, budgets, or other state.

If you need a dynamic decision based on something not in the action payload, expose it through a selector (a typed, cached external lookup with strict timeout and a fallback effect):

selector "user_role" {
  source        = "https://idp.internal/role"
  cache         = "5m"
  on_unavailable = "deny"
  on_timeout     = "deny"
}

rules {
  permit stripe/charge if user_role == "ops" and amount < $5000
}

Selectors keep the pipeline deterministic at decision time (the cache is what's read), with an explicit fallback if the cache misses or the source is down.

Hot-swapping policy

faramesh apply performs an atomic AST swap:

1. Parse and compile the new governance.fms.
2. Validate that every referenced provider and identity resolves.
3. Run faramesh plan against the last 24h of decisions and report the diff.
4. If validation passes, swap the in-memory AST in a single pointer write.
5. Persist the new policy version into the WAL with a hash so faramesh audit verify continues unbroken.

In-flight calls that have already passed step 3 finish under the old AST. New calls see the new AST. There is no window where some rules are old and some are new for the same call.

What's next

• Interception: how the call reaches the daemon in the first place
• Auditing: what gets recorded and how to verify it
• Credentials: the broker and credential sequestration
• FPL reference: every condition and effect