Value ceilings, approved destinations, cumulative exposure.
UBAGby Dixit AlgorizmiRequest a pilot UBAG v0.5 · Pilot programme open
The agent can reason.
UBAG decides what it may do.
A deterministic authorization gateway for AI agents. Keep credentials outside the model, evaluate the whole plan, and enforce policy before a protected action reaches production.
Deterministic enforcementGateway-held credentialsPlan-level context
PROPOSED ACTION
payments.transferAGENTtreasury.agent
DESTINATIONexternal_account
VALUE$24,000
PLAN STEPS04
Identity signatureVERIFIED
Capability scopeMATCH
Destination allow-listMISS
Cumulative plan valueOVER LIMIT
DECISIONDENYNo credential released · evidence recorded
DENY BY DEFAULT◆NO MODEL IN THE APPROVAL PATH◆POLICY AS CODE◆AUDITABLE DECISIONS◆
The boundary problem 01
More capable agents create a more consequential permission problem.
An agent that can call tools can move from a bad instruction to a real-world side effect in one request. Prompt rules remain useful, but they should not be the final authority for money, data, infrastructure, or regulated workflows.
UBAG introduces a separate execution boundary: the model proposes an action; deterministic policy decides whether the action is authorized; the gateway releases only the minimum authority required.
Scoped paths, audiences, purposes, and egress controls.
Allowed tools, environments, resources, and change windows.
Review gates, revocation, replay resistance, and evidence.
How UBAG works 02
A SEPARATE CONTROL PLANE
Four transitions. One explicit decision.
The gateway is positioned where intent becomes execution. Each transition narrows authority and emits decision evidence.
Agent proposes
A structured action or plan arrives without direct access to the protected credential.
→
Identity verifies
The request proves possession of an agent key. Verification does not itself grant access.
→
Policy evaluates
Rules inspect capability, plan context, live state, destination, limits, and revocation.
→
Gateway executes
Only an allowed action receives bounded authority and is forwarded with an audit record.
DESIGN RULEIdentity answers “who signed?” Policy answers “may they do this?” Keep those questions separate.
Security model 03
A boundary built from explicit controls, not confidence scores.
UBAG’s public security model is intentionally precise about what is verified, what is authorized, and what remains the operator’s responsibility.
Identity is evidence, not permission
A verified key establishes who signed a request. Site policy still decides what that identity may do.
Credentials stay at the gateway
Agents propose actions without holding the protected upstream secrets required to execute them.
The plan is part of the decision
UBAG can evaluate sequence, cumulative exposure, destination, live state, and explicit limits before execution.
Every allow is bounded
Authorization is scoped to the intended capability, path, value, audience, and time window, not a reusable blank cheque.
Deployment 04
Start beside production.
Move in-path when ready.
Begin in shadow mode to compare proposed decisions against real traffic without changing execution. Graduate selected routes after policy review and integration testing.
Gateway for tool calls
Point a Streamable HTTP MCP client at UBAG. Tool calls are evaluated before they reach the upstream server.
CLIENT → UBAG → MCP SERVERProxy for direct actions
Send structured actions to UBAG. Allowed requests are forwarded with server-side credential injection.
AGENT → UBAG → UPSTREAM APIObserve before enforcing
Generate parallel decisions and policy evidence while the existing production path remains authoritative.
TRAFFIC → OBSERVE → POLICY REPORTOpen + commercial 05
Inspect the protocol.
Operate the product.
We publish the web-layer identity and routing reference. The production gateway adds the controls and operations required to manage consequential agent actions.
OPENUBAG Protocol
- Web-layer identity challenge
- Python and Node reference SDKs
- Request proof and credential validation
- Public security model and test suite
PRODUCTUBAG Gateway
- Deterministic policy engine
- Gateway-held credential vault
- Plan and cumulative-risk evaluation
- Operational audit, revocation, and deployment
Four-week shadow pilot 06
One workflow.
Measured before enforcement.
We connect a representative action feed without changing production execution, encode the agreed policy, observe normal and adversarial cycles, and finish with a documented go/no-go decision.
Discover
Map tools, trusted identity, authoritative state, policy units, and failure modes.
Integrate
Connect the shadow proposal feed, decision evidence, and read-only systems of record.
Observe
Measure policy coverage, review rate, false positives, latency, retries, and attack handling.
Decide
Deliver the evidence, tuned policy, threat-model delta, and route-level recommendation.
DEFAULT OBJECTIVESZero permissive attack-corpus decisions · <2% benign false positives · P95 engine latency below 100 ms
Scope the pilot ↗Questions 07
Clear boundaries need clear language.
Is UBAG another AI safety model?+
No. The enforcement path is deterministic. Optional model-assisted analysis may add caution or route an action for review, but it does not grant permission.
Does the agent receive API keys?+
No. In the commercial gateway design, protected upstream credentials remain in the gateway and are introduced only after an allow decision.
Do I need to rewrite my agent?+
UBAG is designed to sit at the infrastructure boundary. MCP clients can point to a proxy endpoint; direct-API agents can call the gateway before the protected upstream.
What is open source?+
The UBAG web-layer protocol and Python/Node reference SDKs are public. The commercial gateway, including operational policy, vault, plan evaluation, and managed deployment, is a separate product.
DESIGN PARTNERS
Put a deterministic gate between your agents and production.
Start with one consequential workflow in shadow mode. We’ll help map the action surface, encode policy, and measure what the gateway would hold, deny, or allow.