How Faramesh works

Where Faramesh sits (placement)

Your agent runs in some process. It has tools. The framework in use (LangGraph, Claude Code, Bedrock, or another) decides which tool to call, with which arguments, and runs it. Faramesh inserts itself between "decided to call" and "called."

┌──────────────────────────────────────────────────────────┐
│                       Agent process                      │
│                                                          │
│   LLM   ─────────►   Tool router   ─────────►   ???      │
│                            │                             │
└────────────────────────────┼─────────────────────────────┘
                             │   every tool call
            ┌────────────────▼──────────────────┐
            │         Faramesh daemon           │
            │                                   │
            │   policy AST   provider broker    │
            │   WAL + DPR    completion gates   │
            │                                   │
            └────────────┬──────────┬───────────┘
                         │          │
              ┌──────────▼──┐   ┌───▼──────────┐
              │   Real      │   │  Vault, KMS, │
              │   tool/MCP  │   │  audit sinks │
              │   endpoint  │   │              │
              └─────────────┘   └──────────────┘

The agent only sees one of two things, depending on how you wire it:

• The Faramesh SDK shim: a tiny library you import. Replaces your tool list with a wrapped version that calls the daemon first.
• A proxy URL: for MCP clients and HTTP-based runtimes, Faramesh runs a proxy port. You point the client at the proxy instead of the upstream.

Either way: the agent never reaches the real endpoint directly while the daemon is running. There is no opt-out path through the framework, because the framework itself has been redirected.

Three tiers, one mental model

You can mix tiers. A LangGraph agent that also talks to a hosted MCP server can use both the SDK shim and the MCP proxy. Same daemon, same policy, two interception points.

→ Full detail on Interception.

What happens on every call (the pipeline)

A tool call arrives at the daemon. Here's what runs, in order. Each step can deny, defer, or pass.

┌──────────────────────────────────────────────────────────┐
│  1.  Identity check          → who is the agent?         │
│  2.  Lookup matching rule    → first match wins          │
│  3.  Evaluate conditions     → if amount < $500 …        │
│  4.  Check rate limits       → 10/minute per pattern     │
│  5.  Check budgets           → daily ceiling intact?     │
│  6.  Check egress            → host in allow list?       │
│  7.  Apply redactions        → mask args before logging  │
│  8.  Decision: permit / defer / deny                     │
│  9.  Provider broker         → mint scoped credential    │
│  10. Run tool                → only if permit            │
│  11. Write DPR               → hash-chained, KMS-signed  │
│  12. Emit to audit sinks     → Splunk / Datadog / S3     │
└──────────────────────────────────────────────────────────┘

A few important properties of this pipeline:

• Steps 1–8 are pure functions. They take (policy AST, action payload) and return a decision. No LLM, no network call, no file read.
• Same input → same decision, every time. That's what "deterministic" means here. You can replay any decision offline and prove the daemon would make the same one.
• Defer stops the pipeline at step 8. The action is queued for a human; the credential is not brokered, the tool is not run.
• Deny stops the pipeline at step 8. Same. Nothing else happens.

Worked example

You wrote this policy:

agent "support-bot" {
  default deny

  rules {
    permit search_docs
    permit stripe/refund if amount < $500
    defer  stripe/refund if amount >= $500
    deny   stripe/payouts reason "platform team only"
  }

  rate_limit "stripe/*": 10 per minute

  budget daily {
    max       $500
    on_exceed defer
  }

  redact stripe/refund args: ["card_number"]

  egress {
    allow = ["api.stripe.com", "docs.example.com"]
  }
}

Three calls come in:

The same three calls, the same policy, every time. That's the entire model.

What guarantees the daemon provides (trust boundary)

The daemon is the only thing trusted to enforce policy on this host. Concretely, the daemon guarantees:

• No tool call bypasses the pipeline. As long as the agent goes through the SDK shim or proxy (and you've enabled OS-tier on Linux/macOS for hostile-agent setups), there's no path to the real endpoint that skips the daemon.
• Policy can't be silently swapped. faramesh apply is the only way to update the in-memory AST. The daemon does not re-read governance.fms between applies.
• Records can't be silently rewritten. The WAL is append-only and hash-chained. With KMS signing enabled, even compromising the host doesn't let you forge plausible audit history.
• The agent doesn't hold long-lived secrets. Credentials are brokered at the call site (step 9) and have lifetimes you set (typically 30s–5min). They go to the SDK shim or proxy, not to the agent's environment.

What the daemon does not guarantee:

• It doesn't stop a malicious tool from doing something out-of-band that doesn't touch its declared API. (Mitigation: OS-tier sandbox on Linux/macOS. See Architecture.)
• It doesn't make a wrong policy correct. If your governance.fms says permit *, that's what it'll do.
• It doesn't replace network segmentation, IAM, or the rest of your security stack. It augments them at the agent decision layer.