Bounded Contextual Authority: A Framework for Portable, Machine-Verifiable Authority in Autonomous Systems

Allan Sendagi, Founder, SafeHaven AI / NOMOS Protocol. August 2026.

Abstract

Autonomous systems are increasingly capable of taking actions across organizational and technical boundaries. Existing security and governance architectures generally treat authorization as a property of an actor, a permission, a policy engine, or a runtime control applied immediately before execution. This paper proposes a different model: bounded contextual authority — authority represented as a portable computational object whose scope, conditions, constraints and validity are explicit, and whose applicability is evaluated within a defined execution context rather than assumed from possession of access. Under this model, an autonomous system does not merely hold a capability; it acts under a recognizable mandate. This reframes the governing interaction from AI → guardrails → tools → execution to AI → authority → action.

NOMOS provides an implemented architecture for testing this proposition: sealed .nomos authority artifacts, deterministic verification, cryptographic provenance, constraints, third-party attestation, lifecycle controls, and — demonstrated independently, live — runtime mediation. That demonstration proves authority can sit inside an autonomous agent's execution path and physically block an action before it reaches a downstream system. It does not yet prove the harder claim this paper is ultimately about: that two independent systems, with no prior relationship, can recognize and act on each other's authority at the moment of action. We call that unresolved step the authority handshake, decompose exactly which existing mechanisms cover part of it and which do not, and propose a path toward it grounded in established trust-chain patterns rather than a new cryptographic primitive.

1. Introduction

The central governance problem created by autonomous systems is not simply that AI can make mistakes. It is that AI can increasingly act. A model can generate a recommendation. An agent can select a tool. A system can invoke an API. A workflow can trigger a transaction. At each step, one question matters more than any other:

Under what authority is this action being taken?

Existing architectures tend to answer this question indirectly. Identity and access systems determine who or what may access a resource. Role-based access control determines whether an actor has a particular permission. Policy engines evaluate conditions. Guardrails constrain model behavior. Tool permissions restrict available capabilities. Each of these is valuable, and none of them is wrong to have. But they share a structural assumption: that authority is something surrounding execution, checked by whichever system happens to be running the agent, rather than something the agent itself carries and can present.

This paper explores the alternative: authority itself can become executable infrastructure.

2. From Permission to Authority

A permission answers a narrow question: can this actor perform this operation? Authority asks a broader one: why is this actor entitled to perform this operation, within what scope, under whose mandate, and subject to which constraints?

Institutions already operate on the second question, not the first. A person may act under a professional license, a delegated mandate, a power of attorney, an organizational role, a regulatory authorization, a contractual obligation, or an institutional policy. In every case, the authority is not a boolean. It carries structure — an issuer, a scope, a subject it applies to, a jurisdiction, conditions, constraints, a validity period, and a provenance trail back to whoever granted it. These relationships are ordinarily expressed in documents and organizational processes built for humans to interpret. Autonomous systems need the same relationships expressed in a form they can compute.

A brief grounding note, since this paper makes architectural claims: in the current NOMOS implementation, several of these properties are already explicit fields on a sealed artifact — issuer (meta.owner), scope (scope + data_contract), rules, per-rule provenance, version, and cryptographic identity (seal). Others — a single unified "subject" or "validity" — are not one named field but emerge from the composition of several mechanisms (temporal bounds, revocation checks, constraint enforcement). That distinction matters for anyone building against this model, and we return to it in Section 5.

3. The Existing Execution Model

The dominant architecture for constraining autonomous systems today can be summarized as:

AI → guardrails → tools → execution

The agent decides on an action; a guardrail or policy layer checks that action; if permitted, the system invokes the tool. This creates specific, structural problems as systems begin to cross organizational boundaries — not implementation bugs a better guardrail would fix.

3.1 Authority is local

The governing logic resides inside the environment operating the policy engine, not with the agent.

3.2 Authority does not travel

An agent may move between environments — a different host, a different integrator, a tool operated by an entirely different organization — while the policy that was meant to govern it remains behind.

3.3 Authority is difficult to verify externally

A third party may observe that a policy engine returned allow, without being able to independently establish what authority was actually applied, or whether the rule set has since changed.

3.4 Policy and execution become separated

The system carrying out the action frequently has no portable representation of the institutional authority under which it is acting — only the fact that, somewhere upstream, a check was passed.

4. Bounded Contextual Authority

We define bounded contextual authority as:

A machine-verifiable representation of authority whose scope, conditions, constraints and validity are explicit, and whose applicability can be evaluated within a defined execution context.

Each word in the name carries specific weight.

Bounded

Authority is never unlimited. It has explicit boundaries: what may be done, what may not, under which conditions, by which actors, within which domain, for how long, and subject to which escalation requirements. A .nomos artifact's governance.constraints and, where an agent manifest is declared, its per-agent cannot_call lists are the concrete mechanism behind this word today.

Contextual

Authority is not meaningful in isolation. Whether an action is authorized depends on the relationship between the authority, the actor, the proposed action, the specific facts of the moment, and the environment it's being evaluated in. The same authority may permit one action and prohibit another, depending on nothing but the amount, the role, or the timing involved. This is what NOMOS's deterministic runtime evaluates at the moment of a proposed action, not once, in advance, for all future actions.

Authority

The system is not merely checking whether an actor has access. It is evaluating whether the actor is acting under a recognized mandate — a claim with an issuer behind it, not a flag that happens to be set to true.

5. Authority as a Computational Object

This leads to the paper's central architectural proposition: institutional authority can be represented as a portable computational object. A useful authority object contains, directly or through composable structures: issuer, subject, jurisdiction, scope, rules, constraints, delegation, provenance, version, cryptographic identity, validity, and lifecycle state.

The property that matters most is portability. The authority is not merely stored inside the system performing the evaluation — it can be issued, carried, presented, verified, and evaluated by another system entirely. This is what the .nomos file is attempting to be: not a policy configuration local to one platform, but a representation of the authority a policy establishes, sealed once and checkable anywhere.

Concretely, in the current implementation: NOMOS ingests an institution's policy documents (and, where available, real historical decisions and outcomes, reconciled against the declared rules) and produces a structured rule set. That rule set is canonicalized (RFC 8785) and sealed with an Ed25519 signature — a cryptographic commitment that anyone holding the artifact and the issuer's published public key can independently verify, with no call back to the issuing platform. A deterministic runtime then evaluates proposed actions against the sealed artifact and returns one of three outcomes: authorized, denied, or escalated to a human. Critically, the runtime does not ask a model to reinterpret the policy at the moment of execution — construction may involve intelligence; execution requires determinism. This is what makes the object's verdicts reproducible: the same inputs against the same sealed artifact always produce the same answer.

6. From Mediation to Handshake

Portability alone does not solve the governance problem this paper opened with. An artifact that can be verified is not the same as an artifact that has been recognized by a party who has never seen its issuer before. This distinction is the paper's central technical claim, and it is easiest to see by walking through three progressively harder architectures.

6.1 Mediation

The most immediate architecture — and the only one demonstrated live to date — looks like this:

Autonomous system
       │
       ▼
External MCP server
       │
       ▼
NOMOS authority check
       │
   ┌───┴────┐
   ▼        ▼
within    outside
boundary  boundary
   │        │
   ▼        ▼
execute   escalate
          │
          ✕
      downstream
       blocked

An independent party, Federico Blanco Sánchez-Llanos, connected an external MCP server to the published nomos-guard policy gateway and drove real tool calls through it against a live, public NOMOS artifact: a request within the artifact's declared threshold was forwarded and executed; a request that crossed it was escalated, and the downstream handler that would have carried out the action was never reached. Real audit hashes were produced for each run, and the integration was built and debugged independently — including discovering, by reading the sealed artifact itself, the correct field name for a value that had silently defaulted to allow under an incorrect assumption.

This is genuine evidence for one half of this paper's argument: authority can be enforced in the path between an autonomous system and the action it wants to take, not merely evaluated on request. It is not yet evidence for the harder claim. In mediation, one system (nomos-guard) asks NOMOS whether an action is permitted under a NOMOS artifact — a single authority domain, one issuer, one relationship. The receiving system is not deciding, on its own, whether to recognize a stranger's authority; it is calling out to the authority's own issuer to ask.

6.2 Portable authority

The next architecture removes that dependency:

AI
 │
 │ authority
 ▼
Receiving system
 │
 │ recognizes / verifies / evaluates
 ▼
Action

Here, the acting system does not ask the issuer whether an action is allowed — it presents the authority itself, and a receiving system, operating its own infrastructure, does the recognizing and evaluating.

6.3 The authority handshake

Fully realized, the exchange looks like a dialogue rather than a query:

AI
 │
 │ "Here is my authority."
 ▼
Receiving system
 │
 │ "I recognize this issuer."
 │ "The authority is valid."
 │ "This action is within scope."
 ▼
Action

The distinction between 6.1 and 6.3 is not a matter of degree. Mediation shows authority can physically stop an action. A handshake shows two systems that never configured a relationship in advance can still transact on authority — which is the property that makes authority genuinely portable across organizational boundaries, rather than portable only within one issuer's own infrastructure.

6.4 What already exists, decomposed precisely

NOMOS's existing mechanisms each cover part of the handshake. None cover all of it. Naming exactly where each one stops is more useful than describing the gap in the abstract:

The pattern is consistent: NOMOS already lets an artifact prove what it is. Nothing yet lets an unfamiliar counterparty decide, on its own terms, whether to act on that proof.

6.5 Toward a protocol

This is not a new category of problem in computing. Public-key infrastructure solves an analogous one for web certificates: a relying party trusts a certificate not because it recognizes the specific signer, but because the signer's key chains to a root the relying party already trusts. The contribution proposed here is not a new cryptographic primitive — it is applying that same trust-anchor pattern to institutional authority, where the thing being chained is not "this domain belongs to this org" but "this issuer's authority over this scope is one you have reason to recognize."

A full exchange would resolve, in sequence:

PRESENT AUTHORITY
      ↓
VERIFY ISSUER
      ↓
VERIFY INTEGRITY
      ↓
CHECK VALIDITY
      ↓
CHECK CONTEXT
      ↓
CHECK SCOPE
      ↓
CHECK CONSTRAINTS
      ↓
AUTHORIZE / DENY / ESCALATE

The second step — verify issuer — resolving whether this specific issuer is one the relying system has reason to recognize, via a trust-anchor mechanism rather than a hand-configured allowlist, is the one link in this chain that does not exist today. Every step around it is already implemented in some form; this step is the open research question the rest of this paper's mechanisms exist to eventually support.

7. Authority Lifecycle

Authority is not a static permission. A useful lifecycle:

ISSUED → VERIFIED → DELEGATED → CONSTRAINED → SUPERSEDED → REVOKED

Issued — the artifact is sealed: hashed and signed under the issuer's key. Verified — any relying party independently confirms integrity and authenticity; this happens continuously, by anyone, not once at issuance. Delegated — authority extended to another actor or system; in the current implementation this is not one mechanism but several (per-agent permission scoping, rule inheritance from a base artifact into a composed child, or an authority organization's policy cascading to subordinate organizations) — worth naming the specific one meant in any given deployment. Constrained — declared boundaries enforced by the runtime independently of rule matching. Superseded — a newer version becomes the active reference; the prior version remains authentic and verifiable for historical decisions made under it, and supersession is routine, not a security event. Revoked — the issuer withdraws a specific version's own validity, a materially different and more consequential claim than supersession.

An artifact may remain authentic while no longer being valid for new execution.

NOMOS-SPEC-006 formalizes exactly this distinction: a detached, issuer-signed revocation statement, bound to the exact artifact hash and version, checkable via a signed, published revocation list — fully offline, without ever mutating the sealed artifact itself.

8. Trust Across Organizational Boundaries

Portable authority raises a question no single artifact can answer on its own: who recognizes it? An organization cannot be expected to accept every authority object presented by every autonomous system that shows up. A receiving system needs a way to establish who issued a claim, whether that issuer is one it has reason to trust, and whether the claimed authority actually covers the domain in question — before it ever gets to checking the artifact's internal rules.

This points toward chains of authority and trust: institutional issuers, delegated sub-authorities, and recognized trust anchors, structured the same way certificate authorities structure trust for the web today. We do not propose a specific chain-of-trust design here — only that this is the architectural layer a handshake protocol will need, and that it is a governance question as much as a cryptographic one: who gets to be a trust anchor for institutional authority is not a decision a protocol specification can make by itself.

9. Governance Implications

If authority becomes portable computational infrastructure, the governance workflow itself shifts.

Today: institutions publish rules → organizations interpret them → developers encode them → systems execute them → auditors reconstruct what happened, afterward, from logs.

Under this model: institutions issue computational authority → agents carry or present it → receiving systems verify it → execution occurs within its declared bounds → the resulting decision remains linked to the specific authority that justified it, at the time it was made, not reconstructed later.

The objective is not to replace institutional judgment with software. It is to make institutional authority legible to software, without removing institutional control over what that authority says.

10. Relation to Computable Authority (R-07)

R-07 proposed a reference architecture in which a governance artifact carries its issuer, scope, delegation, version, and integrity information, evaluated at runtime by a deterministic authorization layer. That architecture treats recognition as a given — an artifact, once compiled and sealed, is assumed to be checkable by whichever runtime encounters it. This paper isolates the one assumption in that picture that does not yet hold in the multi-issuer, cross-organizational case: recognition of an unfamiliar issuer is not solved by the artifact format alone, no matter how completely that format captures scope, delegation, and constraints. R-08 is a refinement of R-07, not a departure from it — it takes one link in that architecture and asks what would actually have to be true for it to hold between two systems that have never met.

11. Open Questions

This model raises questions that are not implementation details — they are the foundations any authority protocol will eventually have to answer.

• Authority recognition — how does a system decide, in general, which issuers it recognizes?
• Trust anchors — who establishes roots of trust for institutional authority, and under what governance?
• Delegation — how can authority be delegated without a delegate exceeding the issuer's own authority?
• Revocation propagation — how quickly must a withdrawal reach every system that might still be relying on the artifact?
• Offline operation — how does a system verify authority when it cannot reach the issuer at all?
• Cross-jurisdiction recognition — how is authority recognized across organizational or national boundaries with no shared legal frame?
• Conflict — what happens when two recognized authorities issue instructions that disagree?
• Sufficiency of context — how much context must be supplied before an authority can be safely evaluated at all?
• Liability — if an autonomous system acts within a genuinely valid authority but the action causes harm, how is responsibility allocated between issuer, operator, and system?

12. Conclusion

The emergence of autonomous systems creates a governance requirement systems did not previously need to meet: they must be able to establish, and present, the authority under which they are acting — not merely their identity, and not merely what they happen to have access to.

This paper has proposed bounded contextual authority as a framework for that requirement, and decomposed, as precisely as the current implementation allows, how much of it NOMOS already provides. An artifact can be genuine. A third party can co-sign it. Authority can sit inside an autonomous agent's execution path and physically stop an action before it happens — demonstrated live, independently, not merely declared. Authority can be withdrawn as cleanly as it was issued. What remains open is the handshake: a system that has never encountered a given issuer before, recognizing that issuer's authority on its own terms, at the moment of action.

"Here is the authority under which I am acting. Do you recognize it, and am I permitted to perform this action?"

If that exchange can become interoperable infrastructure — built, as proposed here, on trust-anchor patterns already proven elsewhere rather than a new primitive — the relationship between autonomous systems and institutional governance changes structurally. Not:

AI → guardrails → tools → execution

but:

AI → authority → action

References

• IETF (2008), RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
• IETF (2015), RFC 7662: OAuth 2.0 Token Introspection.
• IETF (2020), RFC 8785: JSON Canonicalization Scheme (JCS).
• W3C (2025), Verifiable Credentials Data Model v2.0, W3C Recommendation, 15 May 2025.
• W3C (2022), Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, 19 July 2022.
• Sendagi, A. (2026), Computable Authority: A Runtime Reference Architecture for Machine-Executable Law and Governance, NOMOS Protocol Research R-07.
• NOMOS Protocol Working Group (2026), NOMOS-SPEC-001 through NOMOS-SPEC-006, github.com/nomos-spec/spec.
• Blanco Sánchez-Llanos, F. (2026), NOMOS Guard Live Demonstration: Mediation of MCP Tool Calls Against a Published Authority Artifact, github.com/babyblueviper1/invinoveritas.

Author

Allan Sendagi — Founder, SafeHaven AI / NOMOS Protocol — August 2026

This paper is an independent research contribution from the NOMOS Protocol Working Group. It proposes an architecture and names open problems; it does not claim the handshake mechanism described in Section 6 is implemented, only that the surrounding capabilities are, and precisely which one is not.