Pilot program · Limited design-partner places
SPENVERSE Agent Firewall
No AI agent acts without authorization, policy enforcement and an audit trail.
SPENVERSE Agent Firewall sits between your AI agents and the systems they touch. Every action is identified, checked against deterministic policy, held for human approval when required, and recorded as tamper-evident evidence before it executes.
- agent
- support-refund-agent
- action
- payments.refund.create
- amount
- €5,000
- identity
- enrolled · credential valid
- policy
- refund.single_approver
- decision
- REQUIRE_APPROVAL
- approver
- Finance Operations · pending
- execution_token
- withheld until approved
- evidence
- appended · hash-chained
Every request gets exactly one decision:
- ALLOW
- DENY
- REQUIRE_APPROVAL
- REQUIRE_TWO_PERSON_APPROVAL
- ALLOW_WITH_CONSTRAINTS
The problem
Agents now act on your systems. Few organizations can prove who allowed it.
Agents hold real access
AI agents call payment APIs, CRMs, ticketing tools and email on your behalf, often through broad service credentials that were issued for people or scripts.
Prompts are not controls
Instructions in a system prompt can be ignored, overridden or injected. A language model should never be the authority on whether it may act.
Logs are not evidence
When a regulator, customer or board asks why an agent did something, a chat transcript does not answer it. You need the decision, the policy and the approver on record.
Enterprises need deterministic authorization, enforceable policy, human approval for high-risk actions and an audit trail they can hand to an auditor, applied to every agent and every system.
How SPENVERSE works
One control point between every agent and every action
Agents call SPENVERSE before they act. The firewall answers with a single decision, and only allowed actions proceed to execution.
AI Agent
Requests an action: refund, export, update, send.
SPENVERSE Agent Firewall
Receives the request before it reaches a business system.
Identity
Verifies which enrolled agent is asking, using its own credential.
Policy
Evaluates the published policy for this agent, action and context.
Authorization
Returns one deterministic decision from a closed set of five outcomes.
Approval if required
Holds the action for one approver, or two for the highest-risk actions.
Execution
A single-use execution token is issued only once the action may proceed.
Audit Evidence
The decision is recorded as hash-chained, tamper-evident evidence. Every decision is recorded, including denials and held approvals.
hash-chained · signed checkpoints
Decisions and their audit records are persisted before any execution token is issued. Approval-gated decisions never carry a token, and high-risk actions can fail closed to DENY.
Core capabilities
Built for the people who sign off on risk
Agent identity
Each agent is enrolled with its own identity and credentials, separate from human users and shared service keys.
Deterministic authorization
Same request, same policy, same decision. Language models are not a source of authority over allow or deny.
Policy enforcement
Versioned policies evaluated at runtime for every agent action, with drafts and simulation before you publish.
Approval workflows
High-risk actions are held at runtime until an authorized approver decides. Email is not authorization.
Two-person approval
Dual authorization for the actions that warrant it, such as large refunds or bulk data exports.
Execution tokens
Allowed actions receive a single-use execution token, issued only after the decision is recorded.
Tamper-evident audit and evidence
Hash-chained records with signed checkpoints, so alteration is detectable. Export evidence for audits and reviews.
Emergency controls
Freeze a single agent, an environment or the whole organization in one action. Frozen scopes are denied until released.
REST connectors
Govern calls to REST APIs, GitHub, Slack, plus a connector SDK for your own systems.
AI Gateway
Separates model authorization from tool authorization. Content-blind by default: prompts and responses are not persisted, only transported in transit; inspection is opt-in.
Notifications
Approvers and operators are notified of pending approvals, emergency actions and security events.
Tenant isolation
Each organization’s data is separated by row-level security that is forced on every tenant table.
Product demonstration
Watch the firewall decide
Choose an agent action and change the conditions. The same deterministic logic produces each of the five decisions.
DEMOSimulated product demonstration running entirely in your browser. No production system, live tenant or customer data is involved, and SPENVERSE does not move money.
Emergency freeze
Freeze every agent in the organization. Policy is not evaluated while frozen.
The five possible decisions
- ALLOW
- DENY
- REQUIRE_APPROVAL (current decision)
- REQUIRE_TWO_PERSON_APPROVAL
- ALLOW_WITH_CONSTRAINTS
spenverse · decision trace
Simulated- agent
- support-refund-agent
- action
- payments.refund.create
- resource
- order/ORD-48213
- amount
- €5,000
- beneficiary
- original payment method
1. AI Agent — passed
support-refund-agent → payments.refund.create
2. Agent Firewall — passed
Request received before execution
3. Identity — passed
Enrolled agent, credential valid
4. Policy — passed
Matched rule refund.single_approver
5. Authorization — held
REQUIRE_APPROVAL
6. Approval — held
Held for one approver: Finance Operations
7. Execution — held
No token until approval is granted
8. Audit Evidence — passed
Decision recorded and hash-chained
Refunds between €500 and €10,000 need one Finance Operations approver.
- rule
- refund.single_approver
- execution_token
- withheld
- approvers
- Finance Operations
Evidence chain · SHA-256 computed in your browser
- Recording…
Decision: Require approval. Refunds between €500 and €10,000 need one Finance Operations approver.
Where teams start
Enterprise use cases
Financial services and fintech
Refunds, payouts, credit adjustments and KYC triage. Thresholds escalate to one or two approvers; new beneficiaries can be denied outright.
SaaS
Support and success agents that change plans, issue credits or act inside customer workspaces, within limits you define per tenant.
Customer operations
Address changes, cancellations and goodwill gestures allowed within policy, and escalated to a person beyond it.
Healthcare
Agents that schedule, triage or draft messages near patient data, with constrained exports and approval before any disclosure.
Logistics
Re-routing shipments, changing delivery addresses and issuing carrier credits, with context such as shipment status in every decision.
Enterprise AI and agent platform teams
One authorization layer across every agent framework your teams adopt, exposed through a decision API and SDKs.
Trust and security
What exists today, and what we do not claim
In the product today
Deterministic policy engine
Authorization decisions come from policy evaluation, not from a language model.
Tamper-evident evidence
Audit records are hash-chained with signed checkpoints, so alteration is detectable. That is what we mean by tamper-evident, and all we claim.
Content-blind gateway by default
Content-blind by default: raw prompts and responses are not persisted, though the Gateway may transport them in transit. Inspection modes are opt-in.
Fail-closed options
Dual authorization and a fail-closed DENY fallback are available for high-risk actions.
Tenant isolation in the database
Row-level security is enabled and forced on tenant tables, and the application runs as a role that cannot bypass it.
EU-first infrastructure design
The platform is designed to run in the AWS Frankfurt region (eu-central-1).
What we do not claim
No independent security audit has been completed yet, including SOC 2 and ISO 27001. We will update this page when that changes.
General availability has not been declared. Production launch certification is still in progress, which is why we are running pilots first.
SPENVERSE does not make you compliant by purchase alone. It provides controls and tamper-evident evidence; compliance remains your obligation. That is the compliance boundary.
This page shows no customer logos or endorsements. We will name customers only with their written permission.
Pilot program
Request a SPENVERSE pilot
We are onboarding a small number of design partners before general availability. Tell us about your agents and we will reply to qualified requests personally.
Apply
Tell us which agents you run and which systems they can reach.
Scope
A working session to agree workflows, systems and success criteria.
Pilot
Policies, approvals and evidence applied to a small set of real agent workflows.
Review
A decision and evidence review with your security and risk owners.
Not ready for a pilot?
Join the Launch Group
Product updates and launch news for security, risk and AI platform leaders. No sales sequence.
Prefer to talk first? Book Architecture Review