Actor and authority
Agent identity, user identity, delegated authority, credential state and privilege posture.
Home / Platform
Admissibility Control · the platform
One decision authority.
Every consequential action.
Admis converts each proposed agent action into a canonical Action Context, evaluates its admissibility across security evidence, institutional constraint and consequence, then returns a graduated control outcome before any side effect occurs.
The category boundary
Existing systems answer
the surrounding questions.
Each of these layers is necessary, and Admis consumes what they produce as evidence. None of them answers the question that remains.
Identity & authorization
Can this principal invoke this capability?
Guardrails
Is the content or model interaction unsafe?
Agent security
Is this interaction compromised, anomalous or malicious?
Governance
Which obligations and constraints apply to this system?
Admissibility
Admis integrates that evidence and answers the institutional question.Given the authority, evidence, constraints, consequences, reversibility and uncertainty, may this specific action proceed now?
Capability determines what an agent can do. Admis determines what it may do.
The decision boundary
Agents propose. Admis decides what may execute.
An agent can be authenticated, authorized and behaving exactly as designed, and still propose an action that exceeds its autonomous authority. Nothing has to be compromised for a decision to be required. Admis separates the decision from the enforcement: the host-native control point intercepts and applies, Admis determines.
Shadow before Enforce
Watch it decide before you let it act.
Admis runs against real production traffic in Shadow, evaluating every consequential action and recording what it would have done — without the ability to intervene. Enforcement is a separate, explicit authorization.
01
Develop
Local agent plus the Admis SDK. Observe, simulate and enforce locally. Nothing leaves your machine.
Free02
Shadow
Real production traffic. Admis evaluates every consequential action and records what it would have done — and cannot intervene.
Cannot intervene03
Enforce
You authorize Admis to constrain, escalate, require approval, quarantine, block or abort. Explicit, per environment.
Requires authorization04
Scale
Millions of protected actions across platforms, environments and estates under one governed authority.
InstitutionalShadow is designed to be privacy-preserving. A local collector can retain full prompts, arguments and customer records inside your environment while only the redacted decision telemetry you explicitly enable — action class, policy result, risk dimensions, outcome, latency, pseudonymous identifiers — reaches a hosted workspace.
Platform operating model
Open at the edge.
Authoritative at the core.
Separating integration, decision authority and institutional governance is what lets Admis work across a heterogeneous agent estate without any adapter or host inventing its own decision semantics.
01
Runtime Plane
Integration and enforcement edge
Intercepts the proposed action, normalizes host context into a canonical Action Context, calls the Decision API and translates the result into the host’s own enforcement primitive.
02
Decision Authority
Canonical evaluation and control
Applies Admis Security, Admis Decision and Admis Compliance through one Action Context, one Decision API and one authoritative outcome model.
03
Governance Plane
Governed institutional authority
Governs policy lifecycle, enterprise evidence, Shadow and Enforce modes, approvals, ledgering, assurance, administration and system-wide replay. Admis as a whole is the admissibility control plane; this is the layer that governs it.
Canonical Action Context
Every relevant fact.
One decision object.
The Action Context carries the evidence and execution terms needed to evaluate the action as it exists now — not as a generic capability or a standing permission.
Action and target
Tool, operation, final executable arguments, destination, environment and resource sensitivity.
Security evidence
Threat, anomaly, exfiltration, compromise and Zero Trust signals from the security stack you already run.
Institutional constraints
Consent, policy, regulatory obligation, purpose limitation, segregation of duties and approval requirements.
Consequence profile
Magnitude, uncertainty, tail risk, reversibility and admissible alternatives for material decisions.
Execution contract
Decision class, synchronous deadline, failure policy, idempotency key and the host’s actual control capabilities.
schema: admis.action_context.v1 · authenticated, replayable, idempotency-keyed and independent of host-specific semantics
Graduated control
Authority is not binary.
Most host interfaces expose allow or block. Admis returns one of nine canonical outcomes, then deterministically maps that authority into whatever primitive the host can actually enforce.
Proceed
Execute as proposed
- allow
- allow_with_logging_escalation
Modify
Reduce or constrain
- allow_with_reduced_scope
- allow_with_constraints
Verify
Raise the authority required
- allow_with_step_up_auth
- allow_with_human_approval
Stop
Prevent the effect
- quarantine
- block
- emergency_abort
| Reference integration | Control point | Fidelity | allow_with_human_approval maps to | Maturity |
|---|---|---|---|---|
| MCP 2026-07-28 | JSON-RPC tools/call | High | input_required + elicitation | In developmenttarget maturity: Supported |
| LangGraph | wrap_tool_call | Full | Native HITL interrupt | In developmenttarget maturity: Supported |
| OpenClaw | before_tool_call | High | requireApproval | In developmenttarget maturity: Supported |
| Copilot Studio | POST /analyze-tool-execution | Binary | Block + approval reason, then retry | ExperimentalMicrosoft preview interface · Admis integration in validation |
| AWS AgentCore | REQUEST interceptor | High | Custom workflow | Experimentalproof of concept |
Control fidelity is a property of the host, not of the Admis decision model. A binary endpoint cannot express all nine outcomes natively — it can still rely on the same authoritative determination. The complete outcome-to-primitive matrix lives in the developer documentation, with the verified host revision for each row.
One core. Many adapters.
Control that survives the stack.
Admis is independent of the model, the framework, the tool and the cloud. Each adapter performs normalization inbound and enforcement translation outbound. Decision logic stays inside the canonical core.
Framework middlewareLangGraph, OpenClaw and framework-native pre-tool hooks
Protocol gatewayMCP tool calls through an independent enforcement boundary
Managed platformsExternal decision endpoints, request interceptors and MCP-mediated routes
Your own gatewayAn APIM policy, WAF or internal control plane calling the Decision API
→
Canonical Admis core
- Decision API
- Action Context
- Nine outcomes
- Execution contract
- Failure policy
- Trace identity
- Authoritative record
→
Host enforcementAllow, rewrite, constrain, pause, approve, block or abort where supported
Native traceDeterminations surfaced inside familiar development and operations tools
Enterprise operationsOpenTelemetry, SIEM, SecOps and customer-controlled gateways
Adapters translate host semantics. They do not invent decision logic.
Admis Decision
When policy is satisfied
and the answer is still no.
Some actions cannot be resolved by identity, authorization and deterministic rules. The agent is authenticated. It has access. No policy prohibits the action. But the consequence is material and there is real uncertainty about the outcome.
Admis Decision evaluates the consequence distribution rather than a single expected value — simulating outcomes, weighting the tail rather than the average, and comparing the proposed action against admissible alternatives that achieve the same intent at lower exposure.
Reversibility matters as much as magnitude. An expensive action that can be undone is not the same institutional risk as a cheap one that cannot.
magnitudetail riskconditional value-at-riskreversibilityuncertaintyadmissible alternatives
Class 01 · Fast path
Inside the host’s synchronous budget
Deterministic policy, compiled constraints, cached evidence and bounded security checks resolve within the deadline the host allows — Copilot Studio, for example, allows one second before its configured error behaviour applies.
Class 02 · Deep Decision
A separate budget, or asynchronous escalation
Distributional evaluation is a different latency class. Where it is required, the enforcement point holds the action with an explicit reason while Admis completes the evaluation out of band and returns the determination — rather than stretching a synchronous budget it cannot meet.
Every decision carries its class, its deadline and the failure policy that applies if the deadline is missed. Latency figures are published per workload against measured Shadow traffic, not as a universal claim.
Trace and authoritative record
Every decision connected to what happened next.
The Admissibility Trace makes the determination visible where teams already work. The Decision Record preserves the normalized context, the determination, the enforcement result and the execution result for replay and institutional evidence.
- decision_id
- dec_7f21c4
- trace_id
- trace_91af20
- action
- payments.transfer · USD 450,000.00
- outcome
- allow_with_human_approval
- enforcement
- paused · approval requested
- execution
- resumed after approval · succeeded
- replay identity
- bundle v12.4.1 · engine 0.9.7 · schema 1.0
- governance hash
- 4d9a…81c2
The record distinguishes what Admis authorized from what actually executed. Without that distinction there is no audit, only a log.
Host trace
Correlates the determination with the agent run and the originating tool call, inside LangSmith, Copilot or the host’s own tooling.
Admis ledger
Preserves replayable decision and enforcement provenance under the governance identity that produced it.
Enterprise operations
Exports canonical events to OpenTelemetry, SIEM and case-management systems using the same decision identifiers.
Assured profile
Decisions you can take
to an auditor.
High-assurance deployments make later alteration detectable and provide verifiable decision provenance through signed records, trusted timestamps and tamper-evident commitment chains. Attestation is an assurance variant for the Assured profile — not a claim that every developer record is sealed.
An audit trail that can be altered without trace isn’t an audit trail.
Data boundary
Your environment decides where the context lives.
Local Admis sends no telemetry by default. Shadow telemetry is opt-in, redacted at the collector, and the exported fields are documented — along with the fields that never leave your environment.
Managed governance
Adapters call the Admis Decision API over TLS. Fastest path to a governed production authority.
Local collector
A local gateway or collector retains full context. Only normalized or redacted context reaches hosted services.
VPC / on-premises
Runtime, gateway, evidence connectors, ledger and optionally the Governance Plane run inside your infrastructure.
Deployment choice must not change canonical decision semantics. The same action, the same evidence and the same policy produce the same determination whether Admis runs hosted, hybrid or entirely inside your network.
Architectural discipline
Clear boundaries create trustworthy control.
The platform is explicit about what decides, what enforces, what observes and what stays under institutional authority.
Pre-execution is the control path.
Admis evaluates before side effects occur. Post-execution monitoring explains what happened; it cannot substitute for decision authority.
Trace is evidence, not enforcement.
Observability makes the determination visible where teams already work. The host-native enforcement point applies it.
Failure is an explicit policy.
Timeout and unavailability behaviour is governed by a versioned failure policy. Consequential surfaces are designed around block-on-error or fail-to-escalation — a platform default that allows on timeout is a configuration decision, not an accident.
An edited action is a new action.
If an approver changes tool arguments, the edited action is re-normalized and re-evaluated before execution. Approvals bind to a decision, an actor and exact arguments, and expire.
How we describe integrations
- MCP mediation is not the same thing as a platform-native runtime hook, and we do not describe it as one.
- We do not claim all nine outcomes on hosts that expose only allow or block.
- Every integration carries a maturity state — Planned, In development, Experimental, Supported or Admis Certified — against a declared host revision, and public claims use the actual state.
The full certification standard and integration registry live in the developer documentation.
Independent decision authority for agentic systems.
Choose your path