Machine-authorization infrastructure

Authority before execution.

MNDe ensures that consequential machine actions execute only with valid, specific, unconsumed authority for the exact requested action.

01Agent intent Principal requests an action

02MNDe authority plane Policy & delegation

03Exact-action grant Single-use, bound, expiring

04Protected executor Consumes grant, acts

05External system Via credential broker

06Linked evidence Authorization + execution receipts

Request a technical pilot Inspect the architecture

MNDe distinguishes implemented reference components, limited paths, and target-state controls. Production claims require deployment evidence. The status labels used throughout this site are defined under status discipline.

The buyer problem

Monitoring an action is not the same as authorizing it.

Agents are increasingly given broad, standing credentials. Once an agent holds a credential, it can act outside the authorization decision that was supposed to constrain it. A signed audit record describes what happened — it does not, by itself, prevent unauthorized execution.

Standing credentials over-authorize

An agent with a long-lived token can perform actions no one decided to allow, across every code path that token reaches.

Observation is not enforcement

Prompt-injection detection, traffic inspection, and agent monitoring watch behavior. They do not gate the consequential action on specific authority.

Audit logs are after the fact

A tamper-evident log is necessary for evidence, but a record written after execution cannot stop the execution it records.

Core invariant: No consequential machine action executes unless it presents valid, specific, unconsumed authority for that exact action.

MNDe is positioned as authorization infrastructure — a certificate authority, HSM, and tamper-evident black box for machine actions — not as another monitoring layer. The enforceable form of the invariant is short: no valid grant, no protected execution.

Core architecture

Principal → policy → grant → protected executor → broker → evidence.

Select a component to see its responsibility, trust boundary, input, output, failure behavior, and implementation state. Nothing here is described as deployed unless its status label says so.

Status discipline

Implemented / Reference

A real reference artifact or executable implementation exists in this repository.

Limited

An interface or partial path exists, but the complete security boundary is not demonstrated.

Target

Required end-state architecture that is not yet proven in production.

Unproven

A security claim that still needs deployment evidence.

Production Verified

Reserved. Used only when an authentic production artifact supports the claim. Currently unused.

Exact-action grant

One action. One resource. One use.

A grant authorizes a single action against a single resource, with parameters bound by a canonical digest, a short expiration, and a single-use nonce. Changing a meaningful field produces a different grant identity — and fails verification.

Illustrative exact-action grant. The Evidence Lab generates real digests and signatures in your browser.
Field	Value
grant_id	grant:9f2a71c4e0b8
execution_id	exec:4c81a0f7d219
actor	agent:payments-bot
principal	service:release-orchestrator
authority	delegated:release-merge
action	merge_pull_request
resource	github.com/acme/payments
environment	reference
canonical_param_digest	sha256:2b8f…c1a4 (illustrative)
limits	max_risk=medium; required_checks=[ci/build, ci/tests, security/scan]
policy_hash	sha256:7d3e…9f02 (illustrative)
delegation_tip	delegation:release-orchestrator->payments-bot
issued_at	2026-08-20T17:00:00Z
expires_at	2026-08-20T17:02:00Z
nonce	nonce:1f6b…8ad2 (single-use)
max_uses	1
issuer_key_id	key:authority-3ab1
sig_alg	ECDSA P-256 / SHA-256 (ES256)
signature	MEUCIQ…<base64> (illustrative)

Mutation invalidates the grant

Authorized

merge_pull_request(
  repository=acme/payments,
  pr=4182,
  head_sha=a19f…,
  method=squash
)

ALLOW — matches the bound canonical digest.

Mutated

merge_pull_request(
  repository=acme/payments,
  pr=4183,
  head_sha=a19f…,
  method=squash
)

REFUSE / SCOPE_MISMATCH — digest differs; provider never contacted.

Grant lifecycle

Requested → issued → reserved → consumed → executed → receipt.

A grant is single-use. Reservation and consumption are atomic, so under concurrent presentation exactly one executor wins. Every path also has a terminal alternative.

Limited

Delegation attenuation

Authority can be delegated, but only narrowed. A delegate can never exceed the authority of its delegator; the delegation-chain tip is bound into every grant and resolved during verification.

Target

Revocation & freshness

Revoked delegation must fail closed. Verifiers must check revocation within a freshness window; a stale checkpoint yields INDETERMINATE, never a silent allow.

Credential dispossession

The agent never holds the upstream credential.

01AgentRequests authority

02GrantIssued to the request

03Protected executorValidates & consumes

04Credential brokerReleases narrow credential

05ProviderAccepts executor identity only

What dispossession requires

The agent does not hold the upstream production credential.
The agent cannot retrieve the credential from the broker.
Only the protected executor identity is accepted by the external provider.

Target

Protected-path non-bypassability

Non-bypassability must be enforced by provider permissions, identity policy, and network boundaries — not by voluntary SDK usage. Until a deployment enforces this, it is target-state, not a current fact.

Evidence

Two signed receipts, cryptographically linked.

Authorization and execution are recorded as separate, independently signed objects and bound together, so the record of what was authorized cannot silently diverge from what was executed.

Authorization receiptLimited

// signed by the authority key
{
  "type": "authorization",
  "statement": "MNDe authorized execution X
             under policy P using grant G",
  "execution_id": "exec:4c81…",
  "grant_hash": "sha256:…",
  "policy_hash": "sha256:…",
  "issuer_key_id": "key:authority-3ab1"
}

Execution receiptLimited

// signed by a separate executor key
{
  "type": "execution",
  "statement": "Executor Y used grant G for
             execution X and observed result Z",
  "execution_id": "exec:4c81…",
  "grant_hash": "sha256:…",
  "authorization_receipt_hash": "sha256:…",
  "result_hash": "sha256:…",
  "executor_key_id": "key:executor-8ad2"
}

Binding fields

Linked by

execution_id
grant_hash
authorization_receipt_hash
result_hash
issuer / executor key id
observation timestamp & signature

Offline verification sequence

Parse the bundle
Canonicalize each object
Validate the trust root
Verify both signatures
Resolve the delegation chain
Check revocation freshness
Confirm grant ↔ execution linkage
Correlate the observed result
Check witness inclusion
Emit a final verdict

Target

Witness checkpoints

Independent witnesses and a transparency log provide inclusion and consistency proofs, so no single party can present a split view of the record.

Limited

Modular content-security inputs

Optional content-risk adapters feed signals into policy evaluation. They inform the decision; they never replace the requirement for a valid, specific, unconsumed grant.

Reference integration

GitHub protected-merge.

The first concrete integration binds authorization to a single pull-request merge. Select a scenario to see the expected verdict, whether the provider is contacted, and why. Provider calls are labeled reference behavior — no external system is contacted from this page.

Bound authorization fields

Repository & pull-request number
Expected head commit
Base branch & merge method
Required checks & risk ceiling
Execution id & expiration
Single-use nonce (max uses)

Authorized flow

Agent requests permission to merge a specific pull request → MNDe evaluates policy and delegation → issues an exact-action grant → the protected executor atomically consumes it → the credential broker releases a GitHub App installation credential to the executor → the executor merges the exact authorized commit → MNDe emits linked authorization and execution receipts.

Implementation Evidence Lab

Real cryptography, honest labels.

This lab runs ECDSA P-256 / SHA-256 locally in your browser. It generates separate authority and executor keys, canonicalizes and hashes an exact-action request, signs two linked receipts, verifies them, detects a parameter mutation, and exports a downloadable evidence bundle. Its source lives in this repository.

Browser reference evidence — not production deployment evidence Reference

The exported JSON contains public verification material and an explicit list of limitations. The production-verified count is zero: a browser simulation is never labeled production verified.

Acceptance controls

Console

Attack & failure scenarios

What each failure does, and where it is caught.

For every scenario: the violated invariant, the detection point, the enforcement point, the expected verdict, whether the provider call begins, the evidence emitted, and the residual risk. Nothing here claims a red-team result — these are the designed behaviors and their honest current limits.

Implementation blueprint

From authority boundary to ecosystem.

Build order, most security-critical first.

Authority boundary

Canonical request schema
Exact-action grant
Deterministic hashing
Signature profile
Atomic consumption ledger
Protected GitHub executor
Credential broker
Provider-enforced non-bypassability
Negative-path test suite

Independent evidence

Dual receipts
Offline verifier
Delegation chains
Operator review workflow
Key lifecycle
Evidence-bundle export

Resilience

Signed revocation service
Freshness policy
Transparency log
Merkle proofs
Independent witnesses
High-availability executor domains
Failure-recovery tests

Ecosystem

AWS executor
Payment executor
Database executor
Deployment executor
Content-security adapters
Policy portability
External trust federation

Buyer-facing proof requirements

Every claim carries its evidence status.

Representative claims and the artifacts required to move each from reference to production.
Claim	Required artifact	Status	Remaining blocker
Agent cannot access the provider credential	Agent secret inventory + broker audit log	Target	Deployed broker with enforced isolation
Direct provider bypass is denied	Failed direct-call transcript + provider permission export	Unproven	Provider-enforced executor identity
Grants are single-use under concurrency	Linearizability history + provider request log	Limited	Deployed ledger test
Receipts verify offline	Signed receipt bundle + offline-verifier output	Reference	Independent verifier packaging
Revocation is timely	Revocation timing trace	Target	Deployed revocation service
Record cannot be split	Witness signatures + inclusion/consistency proofs	Target	Independent witnesses

Technical pilot

Prove the boundary on one merge.

The pilot centers on the GitHub protected-merge integration. The objective:

An automated agent can merge one specifically authorized pull request.
It cannot mutate or replay that authority.
It cannot access the GitHub credential.
It cannot bypass the protected executor.

Success is measured against those four conditions with the evidence artifacts listed under proof requirements. If a condition is not yet demonstrable, the pilot reports it as such rather than claiming it.

Request a technical pilot Open the Evidence Lab