architecture
How it works inside.
Every tool call passes through an 11-step pipeline before it executes. The pipeline is backed by a nine-layer enforcement stack that uses OS-level controls , not just application-level checks. On Linux with root, all nine layers activate. On other platforms, Faramesh picks the strongest available subset.
Deep dive: trust boundaries and data flow
There are four hard trust boundaries in the runtime path: (1) agent runtime to Faramesh ingress, (2) policy engine to credential broker, (3) broker to downstream tool/API, and (4) decision write-ahead log to DPR verification chain. Each boundary enforces different invariants. For example, boundary (2) guarantees credentials are never released before policy permit, and boundary (4) guarantees audit integrity after execution.
The canonical action format (CAR) is the contract across boundaries. CAR captures principal identity, tool identity, normalized args, session state, delegation context, and policy-relevant metadata. Because every adapter maps into CAR, SDK/HTTP/gRPC/MCP all share identical enforcement behavior.
Architecture overview
AGENT PROCESS
Framework dispatch
Auto-patch layer
Faramesh SDK
↓
KERNEL (LINUX)
seccomp-BPF
eBPF probes
Landlock LSM
Network ns
→ unix socket →
FARAMESH DAEMON , 11-STEP PIPELINE
1. Kill switch
2. Phase check
3. Pre-scanners
4. Session state
5. History ring
6. Selectors
7. Policy engine (FPL)
8. Decision
9. WAL write
10. Async DPR
11. Return
PERMIT → Credential Broker
DENY → blocked
DEFER → human
Decision pipeline
When an agent calls a tool, Faramesh runs it through these steps in sequence. If any step fails or denies, the action never reaches the real tool.
1
ReceiveSDK · HTTP · gRPC · MCP
2
Identifyverify agent identity
3
Sessioncheck budget & purpose
4
Canonicalizenormalize to CAR format
5
EvaluateFPL rules, first match wins
6
Delegationverify chain & ceiling
8
Credentialissue scoped secret
9
Executerun tool or hold for human
10
Recordwrite to DPR chain
11
Telemetryemit metrics & traces
Nine-layer enforcement stack
Faramesh combines application-level and OS-level enforcement. This is not a "best effort" system , on Linux, the kernel itself blocks unauthorized actions.
LAYERWHAT IT ENFORCESPLATFORM
1. Framework patchHooks into the agent framework's tool dispatch function. Zero code changes needed. Works with 13 frameworks.All
2. seccomp-BPFRestricts which system calls the agent process can make. Unauthorized syscalls are killed by the kernel.Linux
3. eBPF inspectionInspects system call arguments inside the kernel before they execute. Catches evasion attempts.Linux
4. Landlock LSMRestricts filesystem access to only the paths the policy allows. The agent cannot read or write anything else.Linux 5.13+
5. Network isolationPlaces the agent in a network namespace. Only endpoints allowed by the policy are reachable.Linux
6. Credential brokerStrips ambient API keys from the agent environment. Issues short-lived, scoped credentials only after policy permits.All
7. eBPF baseliningLearns normal agent behavior patterns and flags anomalies in real time. Detects novel attack patterns.Linux
8. MicroVMRuns the agent in a Firecracker or Kata container for hardware-level isolation. Full process and memory boundary.Linux
9. Policy engineEvaluates every tool call against FPL rules. The final authority. Deterministic, no AI in the loop.All
On macOS and Windows, layers 2–5 and 7–8 are not available. Faramesh uses proxy-based network interception and credential brokering instead. The policy engine and framework patching work on every platform.
Trust levels
Faramesh reports the enforcement level so you always know how protected the agent is.
LEVELACTIVE LAYERS
STRONGAll 9 layers active. seccomp + Landlock + netns + eBPF + credential broker + policy engine.
MODERATELandlock + proxy + credential broker + auto-patch + policy engine. Linux without root.
PARTIALProxy-based interception + credential broker + auto-patch + policy engine. macOS / Windows.
CREDENTIALCredential broker + auto-patch + policy engine only. Serverless environments.