faramesh.devBETA
docsgithubcommunityget started →

docs

Getting Started

Core

FPL

Governance

Operations

Reference

github ↗slack ↗community ↗

concepts

What Faramesh is.

Faramesh is the execution control plane for AI agents. It sits between the agent and the outside world. Every tool call passes through Faramesh before it runs. The agent never touches a real API, database, or file system directly , Faramesh decides whether the action is allowed, holds it for a human, or blocks it entirely.

Most "AI governance" tools add a second AI to watch the first one. That's probability watching probability. Faramesh uses deterministic rules , code that evaluates the same way every time. If your policy says "block all shell commands," no prompt injection, jailbreak, or edge case changes the outcome. The answer is always no.

Deep dive: threat model

Faramesh is built for high-impact agent actions where a single bad tool call can cause direct business harm. The primary threat classes are: prompt injection leading to unauthorized tools, credential exfiltration from runtime environments, lateral movement through delegated agents, policy bypass via framework internals, and post-incident ambiguity where no one can prove what happened.

The control boundary is explicit: the Action Authorization Boundary (AAB). Every action must cross this boundary in canonical form before execution. This is what makes enforcement non-bypassable in practice. If an action is not represented as a canonical action and evaluated by policy, it does not run.

Deep dive: deterministic evaluation semantics

Faramesh does not rank likely outcomes; it computes a deterministic verdict. Decision order is fixed: identity and session checks first, then selectors/context enrichment, then rule evaluation (first match wins unless deny! applies), then delegation/budget ceilings, then credential issuance, then execution routing. No model-generated judgement is used at decision time.

This is why incident response is tractable. When a decision is challenged, you can replay the same canonical action against the same policy and get the same result, then verify the corresponding DPR record in the hash chain.

Why it's different

Faramesh is the only governance platform that combines all of these in one system: identity verification, policy enforcement, session budgets, credential brokering, delegation chains, human approval workflows, kernel-level sandboxing, tamper-evident audit, provenance signing, incident response, and full observability , all enforced with code, not AI.

Governance layers

Each layer adds a different kind of protection. Together, they form a complete governance stack from identity to audit.

#LAYERWHAT IT DOES
01IdentityEvery agent has a verified identity. You always know which agent is acting and whether it's been tampered with.
02Policy EngineRules written in FPL decide what happens to every tool call: permit, deny, or defer. First match wins. Deny means deny.
03SessionsEach interaction has a start, end, purpose, and budget. When the budget runs out, all calls are denied until the session is closed.
04Credential BrokerAPI keys never live in the agent's environment. Faramesh strips them and issues short-lived credentials only after the policy says yes.
05DelegationOne agent can grant another a subset of its permissions. Each step in the chain can only narrow scope , never widen it.
06Human RoutingDeferred actions wait for a human to approve or deny. The agent pauses. Nothing runs until someone decides.
07SandboxOn Linux: seccomp-BPF, Landlock, eBPF, network namespaces. On macOS/Windows: proxy-based interception. The agent cannot escape.
08Audit & DPREvery decision is written to a tamper-evident chain. Each record links to the previous with a SHA-256 hash. If any record is altered, verification catches it.
09ProvenancePolicies and model artifacts are cryptographically signed. You can verify at any point that nothing was changed after deployment.
10Incident ResponseDeclare, isolate, collect evidence, resolve. All incident actions are recorded in the audit chain and linked to the triggering decisions.
11ObservabilityPrometheus metrics, OpenTelemetry traces, and structured logs. Every decision emits telemetry you can route to any backend.

Observability integrations

Faramesh exports metrics, traces, and logs in open formats. Connect to any observability platform you already use.

PLATFORMHOW IT CONNECTS
Prometheus / GrafanaScrape the /metrics endpoint for real-time dashboards, alerts, and SLO tracking.
DatadogSend OpenTelemetry traces and metrics to Datadog APM via the OTLP exporter.
New RelicForward OTLP data to New Relic for full-stack observability across your agent fleet.
OpenTelemetryNative OTLP export works with any compatible collector, backend, or vendor.

Need help? Use any of these support options.

open an issuejoin slackcommunity/forum
MIT License
docsgithubcommunityget started →