Replay and idempotency
The same Idempotency-Key and canonical request return the same decision. Reusing the key with materially different content fails closed. Replay pins the bundle, engine, schema, timestamp and governance hash.
Home / Documentation
Admis Runtime Preview v0.1
Implement Admis.
Choose an implementation route, configure the runtime, call the Decision API, and verify behavior before moving from observation to enforcement.
Contract stability
The nine canonical outcomes are normative for the current major version. Changes within a major version are additive. Breaking changes require a new major version and at least 12 months’ deprecation notice. Admis Runtime Preview v0.1 is a release label; integration maturity is reported separately on every route.
How Admis operates
Six steps.
Every implementation.
Proposed action
the agent intends to call a tool
the agent intends to call a tool
↓
Action Context
host intent normalized
host intent normalized
↓
Admis determination
Security · Decision · Compliance
Security · Decision · Compliance
↓
Canonical outcome
one of nine
one of nine
↓
Host enforcement
translated to native controls
translated to native controls
↓
Trace + record
what was authorized, what executed
what was authorized, what executed
Choose an implementation path
Three ways in.
One decision authority.
Maturity uses one vocabulary across the platform: Planned, In development, Experimental, Supported and Admis Certified. No surface is described beyond its actual state.
01
Build into an agent
Developer implementation
Add the decision boundary at the point where your system can still pause, constrain, rewrite or stop an action. Start in observe mode; nothing changes until you authorize it.
Decision APIPOST /v1/decisions/evaluate · REST, any languageIn development
Python SDKadmis · middleware, client, CLIIn development
TypeScript SDK@admis/sdk · client and adaptersIn development
OpenClaw pluginbefore_tool_call · rewrite, block, requireApprovalIn development
LangGraph middlewarewrap_tool_call · composes with native HITLIn development
MCP Gatewaytools/call · one boundary for many toolsIn development
Package names and install paths are launch targets and are validated on a clean machine before release. Control fidelity varies by host. See the Integration Registry on the Developers page.
02
Connect a managed platform
Enterprise agent runtimes
Managed platforms expose their own interception points and their own enforcement primitives. Admis normalizes the payload, determines admissibility, and translates the outcome into whatever the host can faithfully enforce.
Microsoft Copilot StudioPOST /analyze-tool-executionExperimental
AWS Bedrock AgentCoreRequest interceptorExperimental
Microsoft FoundryPartner integration trackPlanned
Salesforce AgentforceMCP-mediated routePlanned
ServiceNowMCP-mediated routePlanned
Adobe CoworkerMCP-mediated routePlanned
These are managed-platform routes, not six available integrations. A binary host interface cannot express all nine outcomes natively. Adobe Coworker is a planned MCP-mediated route, not a native adapter or native runtime integration.
03
Deploy across the enterprise
Institutional decision authority
Establish Admis as the cross-platform decision authority for consequential agent action, with governed policy, enterprise evidence, authoritative records and an explicit data boundary.
Shadow workspaceproduction traffic, evaluated, no interventionIn development
Governance Planepolicy lifecycle, approvals, administrationIn development
Decision Ledgerauthoritative records, replay, retentionIn development
Identity evidenceEntra, Okta, CyberArk · authority and privilegePlanned
Operations exportSentinel, Splunk, SecOps, OpenTelemetryPlanned
Private deploymentVPC or on-premises runtime and ledgerPlanned
Deployment choice must not change canonical decision semantics. The same action, evidence and policy produce the same determination whether Admis runs hosted, hybrid or entirely inside your network.
Configure the runtime
Make the operating posture
explicit.
Start in observe mode, declare the execution contract, and set failure, approval and telemetry behavior before the first evaluated action.
runtime: mode: observe environment: development decision_api: endpoint: http://localhost:8787/v1/decisions/evaluate execution_contract: decision_class: synchronous deadline_ms: 750 failure_policy_id: payments-default-v1 approvals: provider: host ttl_seconds: 900 telemetry: enabled: false redact_arguments: true
runtime.modeobserve evaluates and records locally without changing agent behavior. Use shadow for governed production observation and enforce only after explicit authorization.
execution_contractBinds every request to a decision class, a host deadline and a versioned failure policy.
approvalsDeclares which host owns the approval interaction and how long that authority remains valid.
telemetryLocal telemetry is off by default. Production export is opt-in, scoped and redacted before collection.
Preview configuration is illustrative and versioned with the runtime. Exact package names and defaults are validated before release.
From observation to enforcement
Develop. Shadow.
Enforce. Scale.
Observe is a local mode inside Develop, not a separate stage. Shadow is the production stage where the same determinations run against live traffic without intervening. Enforcement is always an explicit institutional choice.
01
Develop
Evaluate locally without changing agent behavior. Observe is the default mode inside this stage.
mode: observe environment: development telemetry.enabled: false
02
Shadow
Evaluate governed production traffic, write records and measure false positives without intervention.
mode: shadow environment: production enforcement: disabled
03
Enforce
Authorize outcomes to change host behavior through the declared host-native control point.
mode: enforce authority: required failure_policy_id: payments-prod-v3
04
Scale
Centralize assurance, evidence and compatibility requirements across agents, platforms and teams.
governance: centralized evidence: authoritative registry_minimum: supported
Call the Decision API
One request.
One normative outcome.
Send the proposed tool action, target, actor and execution contract before the host executes. Preserve the returned decision and trace identifiers through approval and execution reporting.
{
"action": {
"tool": "payments.transfer",
"operation": "execute",
"arguments": {
"amount": 450000,
"currency": "USD"
},
"target": {
"type": "bank_account",
"id": "acct://beneficiary/8842"
}
},
"actor": {
"agent_id": "agent://finance",
"user_id": "user://123",
"delegation": { }
},
"runtime": {
"platform": "langgraph",
"environment": "production"
},
"execution_contract": {
"decision_class": "synchronous",
"deadline_ms": 750,
"failure_policy_id": "payments-prod-v3"
},
"evidence": { },
"policy_context": { }
}
{
"decision_id": "adm_dec_7f21c4",
"outcome": "allow_with_human_approval",
"permitted": false,
"constraints": { },
"reason_codes": [ ],
"policy_bundle_version": "12.4.1",
"engine_version": "0.9.7",
"decision_schema_version": "1.0",
"failure_policy_applied": "payments-prod-v3",
"decision_path": "fast_path",
"governance_hash": "sha256:4d9a...81c2",
"trace_id": "adm_trace_91af20",
"receipt_id": "adm_receipt_91af20"
}
decision_id identifies the authoritative decision record, while trace_id connects the proposal, determination, host enforcement and execution result. permitted is derived from the canonical outcome for binary host interfaces and is never an independent source of authority.
Two further endpoints complete the lifecycle: POST /v1/decisions/{id}/approval resolves an approval, and POST /v1/decisions/{id}/execution reports what actually executed. Without the second, the record shows what was authorized but not what happened.
Normative outcomes: allow, allow_with_logging_escalation, allow_with_reduced_scope, allow_with_constraints, allow_with_step_up_auth, allow_with_human_approval, quarantine, block and emergency_abort.
Operate and verify
Explain the decision.
Measure the system.
Inspect one trace, summarize operating behavior, and tune the local experience without reducing evaluation coverage.
$ admis explain adm_trace_91af20 outcome allow_with_human_approval reason transfer.amount > 250000 policy payments-prod-v3 decision adm_dec_7f21c4 execution awaiting approval
$ admis summary --since 7d evaluated 12,481 would allow 12,264 would change 217 approvals 41 failures 0
$ admis tune payments.transfer suggestion group repeated notices scope local presentation only evaluation unchanged records preserved
Failure handling
failure_policy_id governs timeout, unavailability and missing evidence. The selected behavior, including block, escalation or any allowed fallback, is written into the authoritative record.
Evidence and execution
Approvals bind to the actor, tool, target and exact arguments. The execution endpoint records what actually happened, preserving the chain from proposed action to final result.
Commands and outputs reflect Admis Runtime Preview v0.1. Exact install paths and CLI behavior remain subject to release validation.
GitHub and releases
One front door.
Four archived previews.
The runtime is the implementation starting point. The earlier repositories document how the platform arrived at its current contract and are read-only.
ADMIS-Runtime
Drop 5, Admis Runtime Preview v0.1. Evaluates, enforces, traces and produces decision records. This is the current implementation starting point.
Open GitHub ↗ADMIS-Action-Guard
Drop 1, the pre-execution boundary.
ArchivedADMIS-Threat-Scenarios
Drop 2, recognizable consequential-action scenarios.
ArchivedADMIS-Agent-Adapters
Drop 3, framework and protocol adapters.
ArchivedADMIS-Policy-Packs
Drop 4, portable institutional rules.
ArchivedHistorical technical previews are read-only and have been superseded by Admis Runtime Preview v0.1. Naming and normative vocabulary may not reflect the current canonical contract. Responsible disclosure runs through SECURITY.md in the runtime repository.
Independent decision authority for agentic systems.