The execution
authority layer
for autonomous
AI agents
Govern every call agents make (API, system calls, tools) through deterministic Cedar policy and structural enforcement.
Firma AI
Central policy authority
Local agent call interception
The missing governance layer in the AI stack
AI agents are transforming enterprise software development, but they operate with blind trust. Unrestricted filesystem access, unaudited network calls, and zero policy enforcement at execution time create real security and compliance exposure for every organization adopting AI agents.
of organizations have experienced unintended actions from their AI agents
of technology professionals identify AI agents as a growing security threat
Source: “AI agents: The new attack surface”, a global survey of security and IT professionals and executives, SailPoint
Introducing Firma AI: deterministic governance for every agent in your organization
One policy authority. Local enforcement on every call. A signed record of every decision. Firma governs agents across the organization without touching a line of agent code.
Intercept every call, every modality, by construction
Firma sits in the agent’s outbound path. Every action an agent takes funnels through the sidecar before it executes: HTTP and HTTPS calls to external APIs, calls to internal services and databases, shell execution, browser automation, and system calls, with the kernel sandbox as the floor.
The agent’s code is untouched. No SDK, no library wrap, no integration work, and no cooperation required from the agent or the developer running it. Because enforcement lives outside the agent process, it holds even when the agent is fully compromised.
Firma AI
Structural interception of every call
Raw calls become enforceable actions
A raw HTTP request is not something you can easily write a policy on. Firma’s Intent Normalizer classifies every intercepted call into a canonical action class and extracts the structured fields that matter: provider, resource, parameters.
Policies are written once against action classes, not endpoints, so they survive a change of tool, provider, or agent vendor. Classification is rule-based and deterministic: the same input produces the same decision every time. No semantic evaluation on the agent runtime.
Action classes
| Intercepted call | Normalized by Firma |
|
|---|---|---|
| What the agent calls | Action class | Extracted resource |
| POST slack.com/api/chat.postMessage | communication.external.send | provider: slack channel: #general |
| mailx -s "Q3 report" ops@acme.com (shell) | communication.external.send | provider: mailx to: ops@acme.com |
| POST api.stripe.com/v1/transfers | payment.transfer | provider: stripe amount: 42000 destination: acct_1M |
| DELETE api.github.com/repos/acme/payments | repo.lifecycle | provider: github repo: acme/payments |
| rm -rf ./infra/state (shell) | filesystem.delete | path: ./infra/state recursive: true |
Govern every agent in the organization from one authority
Coding agents, framework-built agents, off-the-shelf agents and anything your team wrote in-house all run under the same rules. Policy is written once in Cedar, held by the central authority, and distributed to a local sidecar alongside each agent, whoever built it and wherever it runs.
Enforcement then happens locally, so no call waits on a network round-trip, and the sidecar cannot be overridden or tampered with by the agent it governs. Change a rule once and it propagates to every agent, user, group and workspace without restarting anything.
Agents
3 agents
claude-code-local
● Active
- Posture
- strict
- HITL channel
- Telegram
- Pending approvals
- 2 Pending
- Last activity
- 2m ago
codex-dev
● Active
- Posture
- strict
- HITL channel
- Console
- Pending approvals
- 1 Pending
- Last activity
- 8m ago
docs-agent
● Idle
- Posture
- developer
- HITL channel
- Console
- Pending approvals
- None
- Last activity
- 14m ago
Escalate the calls that need a person, block nothing else
Not every sensitive action should be denied outright. Policy can mark specific action classes as requiring explicit human approval, such as a payment above a threshold, a production deployment, or a destructive operation on a repository.
Approvals gate capability issuance rather than individual calls. Approving grants a scoped capability, meaning an action class and a resource perimeter, optionally with a budget, for a fixed time to live. The sidecar then enforces every call in that session locally, and every approval, rejection and revocation lands in the same signed audit trail.
HITL approvals
3 pending · 2 activePending approvals
Active approvals
One authority, every agent, one audit trail
Every enforcement decision, whether allow, deny or abort, emits a signed execution event capturing the agent, the session, the action class, the target, the outcome, and the exact envelope the policy evaluated.
The record is tamper-evident and exports to the SIEM you already run, so agent activity becomes evidence an auditor will accept rather than a log nobody can reconstruct.
Audit
live · last 15 minutes| Agent activity | Decisions |
|||
|---|---|---|---|---|
| Timestamp | Agent | Action class | Decision | Policy |
| 2026-08-04T09:23:04Z | claude-code-local | filesystem.write | Deny | common_secrets_guard |
| 2026-08-04T09:23:00Z | claude-code-local | filesystem.read | Allow | claude-code-local |
| 2026-08-04T09:22:58Z | infra-runner | shell.exec | HITL | infra-baseline |
| 2026-08-04T09:22:54Z | codex-dev | credential.read | Deny | common_secrets_guard |
| 2026-08-04T09:22:51Z | docs-agent | communication.external.send | Allow | docs-agent-scope |
From policy to enforcement in one minute
A walkthrough of defining a policy for an agent in Firma, distributing it, and seeing the first decision land in the audit log.
See how Firma can govern your own agents
Thirty minutes, technical, no slides. We’ll walk through Firma enforcing on a live agent, write a policy against one of your own use cases, and show you the audit record it produces.