Verifiable Enterprise Authority and AI Safety Assurance as External Policy Context for OpenShell

[cstoecker]

Verifiable Enterprise Authority and AI Safety Assurance as External Policy Context for OpenShell

Summary

OpenShell provides a strong operator-controlled runtime boundary for autonomous agents: the Gateway manages sandbox lifecycle and policy delivery, the Policy Prover analyzes proposed policy changes and containment, and the Supervisor enforces policy outside the agent process.

For agents acting across organizational boundaries, a complementary question arises:

How should OpenShell consume externally verifiable evidence that an agent is authorized, appropriately assured, legally eligible, and currently permitted to perform a particular action on behalf of a legal entity, and produce evidence that makes the resulting action attributable and resistant to later repudiation?

This proposal introduces a technically neutral external trust context with three independent inputs:

1. Enterprise authority: who the legal entity is, who may represent it, who operates the AI system, and what the agent is mandated to do.
2. AI safety and quality assurance: what evaluation, management-system, or conformity-assessment evidence applies to the exact system and configuration being used.
3. Legal and compliance context: which jurisdictional, sectoral, contractual, or transaction-specific requirements apply, which approvals or formalities remain necessary, and which evidence must be retained.

The external context would not grant access directly or declare an action legally compliant. A trusted verifier or policy decision point would validate credentials and status, normalize the resulting claims, and derive a candidate admission context or policy. OpenShell would remain the local enforcement authority, and externally derived permissions could never exceed the operator-owned boundary.

The proposed European Business Wallet Regulation is a particularly relevant implementation path. Its objective is a harmonized, legally recognized mechanism through which businesses can identify and authenticate, exchange trusted documents, sign, seal and timestamp, and delegate authority through role- and mandate-based authorization. The Commission proposal explicitly includes the issuing and delegation of mandates in a legally recognized manner; the Council's June 2026 negotiating position likewise identifies delegation of legal authority as a core wallet capability. At the time of writing, the legislative procedure is still in progress, so the final legal and technical design should not be assumed.

The OpenShell abstraction should remain independent of any one jurisdiction, credential format, identity system, or assurance scheme. European Business Wallets, verifiable credentials, enterprise PKI, regulated registries, and conventional certification databases are possible implementations—not prerequisites.

The intended outcome is a continuous evidence chain:

legal entity and representative
        → accountable AI operator
        → bounded Agent Mandate
        → applicable assurance and compliance conditions
        → OpenShell admission and enforcement
        → attributable runtime evidence

This chain can support legal compliance, auditability, and non-repudiation. It does not by itself determine legal effect, contractual liability, regulatory conformity, or the admissibility and weight of evidence; those remain dependent on applicable law and the facts of the transaction.

Motivation

Workload identity answers which technical workload is making a request. It does not, by itself, establish:

• which legal entity the workload represents;
• which person or organizational function had authority to delegate to it;
• which organization is accountable for operating the AI system;
• the permitted purpose, transaction value, resource scope, geography, counterparties, or time window;
• whether the delegation has expired, been suspended, or been revoked;
• whether the deployed model, tools, policy, and configuration match an evaluated baseline;
• whether relevant external assurance remains valid;
• which legal, regulatory, contractual, or sector-specific requirements govern the action;
• whether a required signature, seal, approval, segregation of duties, human decision, or regulated intermediary is present;
• whether the eventual action can be attributed to the legal entity, representative, operator, agent, mandate, policy, and runtime state that authorized it.

These questions matter for procurement, supply-chain operations, finance, regulated workflows, critical infrastructure, and cross-company agent-to-agent transactions.

Authority and assurance should remain separate:

• A valid mandate does not demonstrate that an AI system is safe or fit for the intended use.
• A successful TEVV result or ISO/IEC 42001 certificate does not authorize an agent to act.
• A conformity-assessment credential does not replace runtime policy.
• OpenShell enforcement does not establish legal representation.
• A technically permitted action is not necessarily a legally compliant action.
• A complete audit record can support non-repudiation, but it does not predetermine legal liability or prevent an authorized party from challenging an action.

The runtime admission decision should therefore evaluate the intersection of these concerns.

Legal compliance as policy context

For regulated or legally consequential actions, the admission decision may need a jurisdiction- and transaction-specific compliance profile in addition to authority and assurance. Examples include:

• required actor roles, professional licenses, or regulated permissions;
• monetary or risk thresholds that trigger dual control or human approval;
• signature, seal, timestamp, registered-delivery, or record-retention requirements;
• sanctions, export-control, procurement, financial-services, product-safety, or sector-specific checks;
• restrictions on delegation, automated decision-making, data location, or cross-border transfer;
• mandatory disclosures, notices, withdrawal rights, or escalation paths.

This context should be supplied by an operator-selected compliance service, policy decision point, or jurisdiction profile. OpenShell should enforce the resulting technical constraints and record the decision inputs it can observe; it should not be expected to interpret open-ended law or certify compliance.

Attributability, accountability, and non-repudiation

These properties are related but should not be conflated:

• Attributability links an action to a legal entity, representative, operator, agent/workload identity, mandate, policy generation, decision, time, and outcome.
• Accountability identifies the natural or legal person responsible under governance, contract, or law. It cannot be inferred from a workload identifier alone.
• Non-repudiation support preserves signed or sealed provenance, trusted timestamps, delivery evidence, decision records, and tamper-evident runtime observations so that a later denial can be assessed against verifiable evidence.

The proposal uses “non-repudiation” in this evidentiary and security sense. It does not mean that a cryptographic signature makes an action automatically lawful, eliminates fraud or key-compromise defenses, or conclusively allocates liability.

European Business Wallets as an authorization and mandate layer

The proposed European Business Wallet framework is designed for more than business identification. It is intended to support role- and mandate-based authorization, including delegation to representatives, controlled and auditable access to wallet functions and transactions, and legally recognized business interactions. Related wallet capabilities—electronic signatures, seals, timestamps, attestations, and qualified electronic registered delivery—can contribute to attribution and non-repudiation evidence.

That makes the framework a useful candidate source for the legal-entity, representation, and mandate layers in this proposal. However:

• the wallet authorization system does not replace powers of attorney or legal mandates governed by Union or national law;
• national administrative and procedural requirements continue to apply;
• an Agent Mandate for runtime admission must remain distinguishable from a formal legal mandate, unless the applicable legal framework expressly recognizes their equivalence;
• the final European Business Wallet Regulation and implementing acts may change during the legislative process.

OpenShell should therefore consume a neutral, typed authority context rather than embedding current draft European Business Wallet semantics directly in its core policy model.

Stakeholders and expected value

The proposal is intended to create value across the agent ecosystem without making OpenShell the owner of business semantics or regulatory determinations.

NVIDIA and the OpenShell ecosystem

For NVIDIA and OpenShell contributors, an external trust-context boundary could:

• extend OpenShell from locally authored technical policy to portable enterprise authority and assurance inputs while preserving the operator-owned enforcement ceiling;
• provide a neutral integration point for identity, trust, compliance, and certification ecosystems without hard-coding a particular wallet, credential format, jurisdiction, or vendor;
• strengthen the Open Agent Safety Platform story by connecting pre-deployment assurance, runtime enforcement, and out-of-band Sentry evidence;
• support higher-value enterprise and industrial deployments in which agents act across company or system boundaries;
• create reusable extension points for verifiers, policy decision points, assurance services, and evidence exporters.

AI platform providers and operators

For providers of AI platforms, agent platforms, model-serving infrastructure, and managed agent runtimes, the model could:

• provide one normalized interface for authority and assurance evidence instead of bespoke integrations for every customer or regulator;
• turn customer mandates and assurance conditions into consistent, testable admission controls;
• make deployment gates reproducible across development, validation, staging, and production environments;
• reduce repeated evidence collection by binding approvals and assessments to immutable system baselines;
• enable differentiated platform services for regulated workflows, agentic commerce, and industrial AI;
• shorten security, risk, and compliance reviews through machine-verifiable evidence packages and traceable decision records;
• reduce time to deployment and time to market where the required evidence is already available and reusable.

Customers of AI platforms

For enterprises and public-sector organizations deploying agents, the model could:

• express who an agent represents and what it may do through a revocable, time-bounded Agent Mandate;
• keep organizational authority under the customer's control even when execution occurs on an external AI platform;
• demonstrate that a deployed system matches the model, tool, policy, and configuration baseline that was reviewed or evaluated;
• support faster internal approval by presenting legal authority, operational ownership, assurance, and runtime controls as a coherent evidence chain;
• produce audit-ready records showing which mandate, policy, evidence, and runtime state governed each admitted action;
• revoke or narrow authority without replacing the agent application or granting the platform broader standing access.

This is especially relevant to agentic commerce. Subject to the law, contract rules, liability allocation, and sector-specific requirements in the applicable jurisdiction, an Agent Mandate could express purchasing, negotiation, payment, fulfillment, or counterparty constraints. The mandate would be an input to authorization—not a universal substitute for legal capacity, consent, signature, consumer protection, financial regulation, or human approval.

It is also relevant to industrial AI, where agents may interact with production systems, engineering data, maintenance workflows, robots, or operational technology. In these settings, the trust context can bind authority and assurance to a plant, production line, machine, safety zone, maintenance window, approved toolchain, or evaluated control configuration. OpenShell policy and infrastructure controls would still determine the actions technically possible at runtime.

Assurance, conformity-assessment, and regulatory stakeholders

For TEVV providers, certification bodies, conformity assessment bodies, notified bodies, auditors, and—where applicable—regulators, the model could:

• make scope, limitations, validity, status, and system-baseline binding machine-verifiable;
• improve traceability from an assessment or certificate to the deployment that relies on it;
• enable continuous or event-triggered reassessment when material configuration or runtime state changes;
• reduce repetitive document exchange while preserving issuer provenance and authoritative status sources;
• support targeted review of evidence and exceptions rather than repeating an entire assessment for every deployment.

Compliance and time-to-market impact

The design can support compliance engineering, but it must not claim that possession of credentials equals compliance. Regulatory obligations differ by jurisdiction, sector, actor role, use case, and risk classification. The deployer and its advisers remain responsible for determining which obligations and conformity procedures apply.

Within that constraint, reusable and machine-verifiable trust context can make reviews faster by allowing a reviewer to answer four questions from the same evidence package:

1. Authority: Who authorized this agent, for which organization, purpose, scope, and period?
2. Assurance: Which evaluated or certified baseline covers the deployed system, and with what limitations?
3. Enforcement: Which OpenShell boundary and policy constrained the agent at runtime?
4. Evidence: What actually happened, and did runtime observations remain consistent with the admitted context?

This can reduce manual reconciliation, surface gaps earlier, reuse evidence across deployments, and make approval gates more predictable. The expected result is faster compliance review and deployment—not weaker review and not automatic regulatory approval.

Proposed architecture

flowchart LR
    subgraph EXT["External trust and assurance services"]
        AS["Authentic sources and enterprise issuers"]
        EI["Evaluators, accreditation bodies, CABs and notified bodies"]
        LP["Operator-approved legal and compliance policy sources"]
        ST["Credential status and revocation services"]
        V["Trust-context verifier / policy decision point"]
        AS --> V
        EI --> V
        LP --> V
        ST --> V
    end

    subgraph OS["Operator-controlled OpenShell environment"]
        A["Authority and assurance context"]
        PA["Policy adapter / admission service"]
        G["Gateway"]
        PP["Policy Prover"]
        S["Supervisor"]
        SB["Agent sandbox"]
        A --> PA
        PA --> G
        G --> PP
        PP -->|"candidate within boundary"| S
        S --> SB
    end

    subgraph HW["Optional independent infrastructure layer"]
        SE["NVIDIA Sentry / equivalent monitor"]
        EV["Contextual runtime evidence"]
        SE --> EV
    end

    V -->|"verified, normalized, time-bounded claims"| A
    S -->|"policy decisions and runtime signals"| SE
    SB -->|"agent, tool and data activity"| SE
    EV -->|"reassessment, audit or containment signal"| V

Loading

This preserves three boundaries:

• External issuers make claims only within their trust domains.
• A verifier resolves issuer trust, proof validity, subject binding, scope, freshness, and status.
• OpenShell decides and enforces what the workload may technically do in the local environment.

Trust-domain model

1. Legal identity domain

An authentic source—such as a business register—or an issuer authorized to rely on that source establishes the legal entity. In a European Business Wallet implementation, owner identification data may be issued by a qualified trust service provider, a responsible public-sector body, or the Commission; the model should therefore not assume that every business register is itself a credential issuer.

Output: Legal Entity Credential.

2. Organizational authority domain

This domain establishes representation, operational accountability, and delegation:

Business Register / Authentic Source
                → Legal Entity Credential
                → Representation Credential
                → Operator Credential
                → Agent Mandate Credential

• Representation Credential: a person, role, or organizational function may represent the legal entity within a stated scope.
• Operator Credential: an organization or accountable unit operates a named AI system in a defined environment. This is distinct from legal representation.
• Agent Mandate Credential: the operator delegates a bounded purpose and set of actions to a specific agent or workload for a limited period.

3. AI assurance domain

This domain establishes evidence about fitness, governance, evaluation, or conformity:

• TEVV evidence: evaluation results bound to a defined AI system, model, tools, policy baseline, configuration, environment, test suite, limitations, and validity conditions.
• ISO/IEC 42001 certification: evidence that an organization operates an AI management system within a certified scope. It is not proof that a particular agent action is safe.
• CAB or notified-body credentials: evidence that a conformity assessment body is accredited, designated, or notified for a defined scope.
• Conformity-assessment credentials: results issued for a specific organization, product, system, process, or management system under an identified scheme.

4. Legal and compliance policy domain

This domain translates applicable external requirements into determinate admission conditions. Its inputs may include legislation, regulatory guidance, contracts, sector rules, internal controls, and transaction facts. Because applicability and interpretation are contextual, OpenShell should consume only versioned determinations or profiles from operator-approved sources.

Outputs: Jurisdiction/Transaction Profile and Compliance Determination, including required approvals, formalities, evidence, retention, and escalation conditions.

5. Runtime enforcement and evidence domain

OpenShell evaluates and enforces the local technical boundary. Optional infrastructure-level monitoring, such as NVIDIA Sentry, can independently correlate agent interactions, policy decisions, and tool or data access, produce contextual activity records, and trigger reassessment or containment.

flowchart TB
    subgraph L["Legal identity domain"]
        BR["Business register / authentic source"]
        LE["Legal Entity Credential"]
        BR --> LE
    end

    subgraph O["Organizational authority domain"]
        RC["Representation Credential"]
        OC["Operator Credential"]
        AM["Agent Mandate Credential"]
        LE --> RC --> OC --> AM
    end

    subgraph Q["AI assurance domain"]
        AB["Accreditation or designating authority"]
        CAB["CAB / notified-body credential"]
        ISO["ISO/IEC 42001 certification"]
        CA["Conformity-assessment credential"]
        TE["Independent TEVV evaluator"]
        TV["TEVV evidence credential"]
        AB --> CAB
        CAB --> ISO
        CAB --> CA
        TE --> TV
    end

    subgraph C["Legal and compliance policy domain"]
        PS["Operator-approved policy sources"]
        JP["Jurisdiction / transaction profile"]
        CD["Versioned compliance determination"]
        PS --> JP --> CD
    end

    SR["Status, suspension and revocation"]
    AM --> D["Runtime eligibility decision"]
    ISO --> D
    CA --> D
    TV --> D
    CD --> D
    SR --> D

    subgraph R["Runtime enforcement and evidence domain"]
        OB["Operator-owned OpenShell boundary"]
        EN["Gateway + Policy Prover + Supervisor"]
        RT["Admitted agent action"]
        RE["OpenShell and Sentry runtime evidence"]
        OB --> EN
        D --> EN --> RT --> RE
        RE --> D
    end

Loading

The key trust rule is that evidence from one domain must not silently acquire semantics from another. For example, an accreditation credential can establish a CAB's scope, but it cannot authorize an enterprise agent to purchase goods.

Decision model

For a requested action at time t:

effective_authority(t) =
    mandate_scope(t)
  ∩ assurance_eligibility(t)
  ∩ applicable_legal_constraints(t)
  ∩ operator_policy(t)
  ∩ OpenShell_boundary(t)
  ∩ current_runtime_state(t)

This is a conceptual relation, not a claim that legal compliance can be reduced to set intersection or a requirement that all terms be encoded in the OpenShell policy language. A legal or compliance constraint should affect runtime admission only after an authorized policy source has translated it into a determinate, testable condition.

The Policy Prover should continue to reason about the properties it can formally establish—such as policy containment and risky access expansion. Semantic questions such as whether a purchase serves the mandate's business purpose may remain in a separate admission service or supervisor middleware. The verifier should deliver typed, bounded inputs; it should not be able to bypass OpenShell policy validation or enforcement.

Normalized trust context

The integration contract could use a small, typed, format-neutral envelope. Illustrative fields:

context_id: "ctx-01J..."
evaluated_at: "2026-10-01T14:30:00Z"
expires_at: "2026-10-01T14:35:00Z"

principal:
  legal_entity_id: "urn:example:company:1234"
  agent_id: "urn:example:agent:procurement-4711"
  workload_identity: "sha256:..."

authority:
  representation_credential_id: "urn:example:credential:rep-17"
  operator_credential_id: "urn:example:credential:operator-42"
  mandate_id: "urn:example:credential:mandate-99"
  purpose: "procurement"
  allowed_actions: ["quote.request", "purchase.create"]
  commodity: "battery-components"
  max_transaction_value: 100000
  currency: "EUR"
  valid_until: "2026-10-31T18:00:00Z"

legal_context:
  jurisdiction_profile: "urn:example:policy:eu-de-procurement-v3"
  transaction_type: "b2b-purchase"
  required_approvals: ["human-review-above-50000-EUR"]
  required_evidence: ["signature", "trusted-timestamp", "delivery-receipt"]
  determination_service: "urn:example:compliance-pdp:4"
  determination_id: "urn:example:determination:781"

assurance:
  system_baseline: "sha256:..."
  model_digest: "sha256:..."
  toolset_digest: "sha256:..."
  policy_baseline: "sha256:..."
  evidence_ids:
    - "urn:example:evidence:tevv-2026-44"
    - "urn:example:certificate:iso42001-18"
  limitations: ["human-review-above-50000-EUR"]

status:
  checked_at: "2026-10-01T14:30:00Z"
  next_check_at: "2026-10-01T14:35:00Z"
  result: "good"

provenance:
  verifier_id: "urn:example:verifier:7"
  decision_id: "urn:example:decision:abc"
  evidence_digest: "sha256:..."

The runtime should consume only the minimum claims needed for the decision. Raw credentials and personal data need not be copied into sandbox policy or exposed to the agent. A jurisdiction profile or compliance determination should identify its authoritative source and version; OpenShell should not silently infer applicable law from network location, user locale, or the issuer of a credential.

Runtime admission and evidence loop

Admission should be short-lived, fail closed where required by risk, and re-evaluated when relevant state changes.

sequenceDiagram
    participant A as Agent
    participant S as OpenShell Supervisor
    participant V as Trust-context verifier
    participant G as Gateway / admission service
    participant P as Policy Prover
    participant N as Sentry or equivalent monitor
    participant E as Evidence / status services

    A->>S: Request action
    S->>V: Resolve authority and assurance context
    V->>E: Validate issuer chains, scope, freshness and status
    E-->>V: Current status and evidence
    V-->>G: Signed normalized context + expiry
    G->>G: Bind subject, workload and evaluated baseline
    G->>P: Check candidate policy against operator boundary
    P-->>G: Contained or findings
    alt Eligible and contained
        G-->>S: Admit with decision ID and bounded policy
        S->>A: Execute under enforced policy
        S-->>N: Policy decisions and runtime signals
        N-->>E: Contextual activity evidence
    else Invalid, stale, mismatched or excessive
        G-->>S: Deny, restrict or require review
        S-->>E: Record decision and reason code
    end
    E-->>V: Revocation, drift or assurance invalidation
    V-->>G: Reassess / reduce authority
    G-->>S: Live policy update, stop or quarantine

Loading

Examples of events that should invalidate or reduce admission include:

• mandate expiry, suspension, or revocation;
• representation or operator authority withdrawal;
• issuer or trust-framework status change;
• model, tool, policy, image, or configuration digest mismatch;
• TEVV evidence no longer covering the deployed baseline;
• conformity certificate suspension or scope mismatch;
• runtime drift or high-severity findings;
• inability to obtain status within the configured freshness window.

For legally consequential actions, an evidence receipt should bind at least the normalized context digest, mandate and compliance-determination identifiers, workload identity, effective policy and runtime generation, requested action, enforcement decision, result, and trusted time source. Where required, it can also reference an electronic signature or seal, trusted timestamp, or registered-delivery receipt held outside OpenShell.

Binding and status requirements

The usefulness of the model depends on precise binding. Credentials and evidence should identify, where applicable:

• issuer, subject, holder, and intended verifier or audience;
• legal entity, operator, agent, and immutable workload identity;
• evaluated system, model, toolset, policy, image, and environment digests;
• scheme, scope, test methods, results, limitations, and residual risks;
• issue time, effective time, expiry, and maximum status age;
• status mechanism, suspension or revocation semantics, and replacement relationships;
• decision and evidence identifiers sufficient for audit without exposing unnecessary secrets.

Status is part of the decision, not a background housekeeping process. A signature proves integrity and issuer control; it does not prove that a credential is still valid now.

Security properties

A minimal design should preserve the following properties:

1. No authority amplification. External evidence can narrow or condition access, but cannot expand the operator-owned maximum boundary.
2. Agent non-self-assertion. The untrusted workload cannot authoritatively claim its own mandate, assurance level, or status.
3. Subject and baseline binding. Authority and assurance must resolve to the workload and configuration actually executing.
4. Freshness and revocation. Decisions use explicit expiry and status-freshness bounds, with risk-based behavior when status is unavailable.
5. Separation of semantics. Identity, representation, operation, mandate, assurance, policy, and runtime evidence remain distinguishable.
6. Fail-safe updates. Invalid or unavailable replacement context must not install new credentials or policy alongside an older authorization state.
7. Minimal disclosure. OpenShell receives normalized claims and evidence references rather than every source credential.
8. Evidence integrity. Admission and runtime records bind the context ID, mandate ID, policy version/hash, workload identity, action, outcome, and time.
9. Independent observation. Where available, Sentry or an equivalent out-of-band monitor can produce evidence beyond the agent's control and initiate containment.
10. Format neutrality. The design does not require one credential syntax, transport, trust registry, or jurisdiction.
11. Attributable decisions. Evidence links the action to the represented entity, delegation chain, operator, workload, compliance determination, enforcement state, and outcome without treating the agent as the authoritative narrator.
12. Non-repudiation support. Signed or sealed provenance, trusted time, integrity-protected decision records, and independent runtime observations make later disputes evidence-based while preserving legally valid grounds for challenge.
13. No compliance overclaim. A successful technical admission proves satisfaction of configured machine-testable conditions, not compliance with every applicable legal obligation.

Possible OpenShell integration points

Several approaches appear possible and could coexist:

A. Gateway admission hook

The Gateway requests a normalized external trust context before creating or updating effective sandbox configuration. This provides a central lifecycle and identity binding point.

B. Supervisor middleware

Middleware evaluates action-level claims at request time—for example, a transaction value or API method—without placing dynamic business semantics in static network policy.

C. Policy adapter

An external adapter maps eligible claims to a candidate OpenShell policy. The Policy Prover then verifies containment or reports risky expansion before activation.

D. Dedicated authority-context abstraction

OpenShell could represent external authority separately from provider profiles. Providers describe services, endpoints, and credential bindings; authority context describes the principal and delegated mandate. Keeping these concepts separate may avoid overloading provider configuration.

The proposal does not prescribe which integration point is best. A minimal prototype could begin with an external verifier plus Gateway admission hook, leaving the OpenShell policy schema unchanged.

Illustrative scenario

An autonomous procurement agent has a valid mandate to purchase battery components for Company A up to EUR 100,000. Its representation and operator chains are valid, and the mandate status is current.

The agent was evaluated under TEVV against model version M1, toolset T4, and policy baseline P7. The deployment was upgraded to model M2, but no evidence covers that new baseline.

Legal entity identity          valid
Representation chain          valid
Operator credential           valid
Agent mandate                 valid
TEVV baseline binding         mismatch
Legal/compliance profile      valid
Operator/OpenShell boundary   valid
-------------------------------------
Runtime eligibility           deny or restrict pending review

The valid mandate remains evidence of organizational authority. It does not override the assurance mismatch. Conversely, valid TEVV evidence would not create purchasing authority if the mandate had expired.

Non-goals

This proposal does not attempt to:

• define a universal credential format or global trust registry;
• make OpenShell a certification authority, conformity assessment body, or legal identity wallet;
• treat ISO/IEC 42001 certification as certification of a specific model or action;
• require NVIDIA hardware or Sentry for the external trust-context abstraction;
• place legal or business-policy interpretation inside the Policy Prover;
• make OpenShell determine applicable law, legal capacity, validity of consent, evidentiary admissibility, or allocation of liability;
• treat a technical Agent Mandate as legally equivalent to a power of attorney or other formal mandate in every jurisdiction;
• guarantee that externally issued evidence is correct beyond the configured trust framework;
• replace human review where law, risk, or operator policy requires it.

Suggested phased prototype

1. Define a compact signed trust-context envelope and verifier interface.
2. Bind the envelope to sandbox/workload identity and exact system baseline.
3. Add a Gateway admission hook that accepts, restricts, or rejects context by policy.
4. Map a small set of mandate claims to candidate network/API constraints.
5. Require Policy Prover containment before policy activation.
6. Produce an integrity-protected evidence receipt binding context, mandate, compliance determination, decision, workload, policy, action, outcome, and time.
7. Add status-driven reduction and expiry behavior.
8. Optionally ingest Sentry or equivalent runtime evidence for reassessment and containment.

Questions for maintainers

1. Is external organizational authority best introduced at the Gateway, through Supervisor middleware, through policy generation, or as a separate authority-context abstraction?
2. Should fast-changing mandate attributes remain outside authored OpenShell policy and be evaluated at action time?
3. What is the preferred binding between a verified context and OpenShell's workload identity, policy revision, provider-environment revision, and runtime generation?
4. Could the standalone containment checker provide the operator-owned ceiling for externally derived candidate policy, while the existing proposal-risk prover continues to flag access expansion?
5. Which existing audit or OCSF events could carry context, mandate, assurance-evidence, and admission-decision identifiers without exposing sensitive credential content?
6. How should status loss, stale evidence, and live revocation interact with current last-known-good and policy-update behavior?
7. Is there interest in a minimal reference integration using a format-neutral verifier interface and one illustrative credential profile?
8. Which stable identifiers and signed receipts would OpenShell need to export so a relying party can attribute an action and verify the admission/enforcement chain without receiving sensitive source credentials?

References

• NVIDIA OpenShell overview and architecture
• OpenShell security policy architecture
• OpenShell sandbox and Supervisor runtime model
• OpenShell Policy Prover
• NVIDIA Open Agent Safety Platform and Sentry
• NIST TEVV-Athlon Framework for Evaluating AI Systems
• ISO/IEC 42001:2023 — Artificial intelligence management systems
• ISO/IEC 42006:2025 — Requirements for bodies providing audit and certification of AI management systems
• European Commission proposal for European Business Wallets
• Council negotiating position on European Business Wallets, 9 June 2026
• European Parliament legislative procedure 2025/0358(COD)
• Regulation (EU) No 910/2014 — eIDAS framework
• Directive (EU) 2025/25 — digital tools and processes in company law, including EU digital power of attorney
• Regulation (EU) 2024/1689 — Artificial Intelligence Act