Faramesh: A Local Policy Daemon That Puts Every Agent Tool Call Under Deterministic Control

The Problem: Agent Tool Calls Run Without a Decision Layer

AI agents in production call external tools: CRM APIs, email senders, billing systems. Most frameworks let the model decide when to call them, and the only guard is whatever the developer remembered to wrap. Faramesh addresses that gap directly. The README states its core claim: every agent tool call is a policy decision. It targets engineers shipping agents on LangGraph, CrewAI, Claude Code, MCP, and similar stacks, where a misbehaving agent can send an email or cancel a subscription with no human in the loop. The tool is for those who need governance that does not depend on the model's judgment or on every developer wrapping every SDK call by hand.

How Faramesh Enforces Policies: A Local Daemon, Not an LLM

Faramesh runs as a local daemon that intercepts each tool call before execution. The decision logic is a pure function over the policy and the action payload, so no LLM participates in the decision path. That is a deliberate design choice. The README emphasizes deterministic decisions, meaning the same policy and the same action always produce the same outcome. The daemon can permit, defer, or deny a call. Deferral is the interesting middle state: it routes the action to a human, for example when an email's domain is not internal. The enforcement is non-bypassable because every call goes through the daemon, not through an SDK wrapper that a developer might forget. This architecture moves governance out of the model and into the infrastructure, which is a meaningful shift from prompt-based guardrails.

The Policy Language: Declarative Rules in governance.fms

Policies are written in a domain-specific language called FPL, stored in a file named governance.fms. The README shows a concrete example. An agent block declares default deny, then a rules block lists permits, defers, and denies. Conditions are expressed as if clauses, such as permit email/send if domain == "@yourcompany.com". There is also a rate_limit directive, limiting email/send to 50 per hour, and a daily budget with a max of $20 and an on_exceed action of defer. This language is declarative and compact. The example makes clear that Faramesh is not about free-form natural language policies; it is a structured format that a Go daemon can evaluate deterministically. The FPL reference is linked in the README, but the snippet alone shows the core syntax: agent blocks, rules, rate limits, and budgets.

Interception Tiers: SDK Shim, MCP Proxy, HTTP Proxy, or A2A

Faramesh does not force one integration method. The README lists four tiers: SDK shim, MCP proxy, HTTP proxy, or A2A. This is a practical approach because agents differ in how they call tools. A Python agent using LangGraph can use a shim that wraps the tool-calling loop. A server using MCP can route through an MCP proxy. A generic HTTP client can point at an HTTP proxy. The A2A tier covers agent-to-agent communication. The choice of tier affects how much of the call path is covered. A shim is closer to the model, while a proxy sits at the network boundary. The README claims support for 13 frameworks, including LangGraph, CrewAI, OpenAI Agents, Claude Code, Cursor, and AutoGen. That breadth is a selling point, but it also means you must confirm the adapter for your exact framework version, since adapters can lag behind framework releases.

Identity and Credentials: SPIFFE, OIDC, and Call-Site Brokering

Faramesh binds policy decisions to identity. The README lists SPIFFE SVIDs, OIDC, and cloud workload identity as supported identity sources. Credentials are brokered at the call site, meaning the agent does not hold long-lived secrets. This is a security-relevant design: the daemon can inject credentials only when the policy permits the action. The audit trail then ties the decision to a specific identity. This is more than access control; it is a way to attribute every tool call to a workload identity. The trade-off is that identity setup requires infrastructure, such as a SPIFFE trust domain or an OIDC provider. If you do not already have workload identity, adopting Faramesh adds that dependency. The README does not detail how the brokering works mechanically, so you would need the docs for that.

Audit Trail: Hash-Chained WAL with Optional KMS Signing

Every decision is recorded in a write-ahead log (WAL) that is hash-chained. That means each record includes a hash of the previous record, making retroactive tampering detectable. The README calls these Decision Provenance Records. There is an optional KMS signing step, which adds a cryptographic signature from a key management service. This is a strong audit feature for regulated environments. The hash chain is a common technique in distributed ledgers, and applying it to agent decisions is a sensible fit. The limitation is that the audit log is only as trustworthy as the daemon that writes it. If an attacker compromises the daemon, they could write false records, though the hash chain would still prevent silent alteration of past records. The KMS option mitigates this by requiring an external key for signing, but it adds operational complexity and cost.

Running Faramesh: Install, Version, and Write Your First Policy

Installation is a one-liner from the README: curl -fsSL https://install.faramesh.dev/install.sh | bash, followed by faramesh version to verify. There are also Homebrew, npx, Go install, and build-from-git options. The quickstart leads you through writing your first policy. The CLI is the primary interface, and the stack file is a separate concept for configuration. The README references a Python SDK and a TypeScript SDK, so programmatic access is available. The policy file is named governance.fms, and the daemon presumably reads it on startup. The exact commands for starting the daemon and attaching an agent are not in the README; you would need the quickstart guide. This is a young project, v0.2.0 released in May 2026, so the CLI surface may change between versions.

Limitations and When Faramesh Is the Wrong Tool

Faramesh is not a full agent platform. The README explicitly says it is narrower than Microsoft AGT and operates outside the model output evaluation layer like Galileo Agent Control. That means it does not evaluate the quality of model outputs, only the tool calls. If your governance need includes checking whether the model's response is safe or accurate, Faramesh is not the tool. Another limitation is that deferred actions require a human approval workflow. The README shows defer for billing/cancel_subscription, but it does not describe how the human approves or denies the deferred call. That workflow is presumably in the docs, but it is a critical piece for production use. Also, the deterministic approach means no fuzzy matching. A policy that permits crm/customers/read will not catch a typo like crm/customers/reed unless the action payload is exact. Finally, the project is at v0.2.0, so the API and policy language may evolve, and breaking changes are possible.

Alternatives: Galileo Agent Control and Full-Stack Platforms

The README names two alternatives. Galileo Agent Control operates at the model output evaluation layer, meaning it judges whether the model's response is acceptable before it reaches the user. Faramesh sits earlier, at the tool-call level, and enforces permissions mechanically. These are complementary rather than competing, but if your need is to evaluate output quality, Galileo is the closer fit. Microsoft AGT is a full-stack agent platform, which includes orchestration, model management, and governance. Faramesh is only the enforcement daemon, so if you need a complete platform, AGT is the alternative. The difference in approach is fundamental: Faramesh applies deterministic rules to structured tool calls, while Galileo uses evaluation models and AGT provides end-to-end infrastructure. Your choice depends on whether you want a narrow, auditable control point or a broader platform.

Maintenance, Licensing, and Upgrade Considerations

Faramesh is licensed under Apache-2.0, which permits commercial use, modification, and distribution, with no copyleft obligations. That is a permissive license, so you can embed the daemon in proprietary products. The project has a GOVERNANCE.md, MAINTAINERS.md, and ROADMAP.md, indicating a structured maintenance model. The last push was May 2026, and the release cadence shows v0.1.0 in March and v0.2.0 in May, so roughly two months between releases. That pace suggests active development. The upgrade cost depends on the stability of the FPL language and the CLI. At v0.2.0, you should expect changes. The README mentions a policy pack registry and framework adapters, so upgrading might involve updating adapters when your framework updates. The audit log format is also likely to evolve, so plan for migration of existing logs. The docs site is the authoritative source for the current CLI and FPL reference.

Editorial conclusion

Adopt Faramesh if you run production agents on LangGraph, CrewAI, Claude Code, or MCP and need deterministic, auditable control over tool calls without rewriting your stack. Skip it if your policy needs are trivial or if you expect LLM-based judgment in the decision path, since Faramesh deliberately uses pure functions. Before adopting, verify that your framework is among the 13 supported adapters, test the deferred action workflow with human approval, and confirm that the KMS signing option meets your audit requirements. The project is young at v0.2.0, so plan for breaking changes and check the roadmap in ROADMAP.md.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes