UnGovr Nexus

Overview

AI agents increasingly act on someone's behalf: they retrieve data, submit transactions, and help make decisions that affect people. Enterprise authorization systems can verify who an agent is, who delegated to it, and which server it wants to call. What they cannot see is the legal dimension of the activity itself. A single agent action can touch the law of the place the operator sits, the place the principal lives, the place the target service is established, and the places the affected people and their data are located.

UnGovr Nexus is a policy information point for legal context. A caller describes a proposed agent action in structured form. Nexus returns the jurisdictions that plausibly attach to it and the factual nexus for each, the published instruments involved with primary-source citations and effective dates, the controls those sources call for, what remains uncertain, and what facts are missing. Your policy engine combines that context with your organization's own policy. Nexus informs the decision; it never makes it.

The Problem

Text version of this diagram

A human principal delegates to an AI agent. The agent's request passes through an identity provider, a policy engine, and an authorization server on its way to a resource server; this stack sees identity, scopes, and destination. Above the stack, disconnected from it by a gap labeled "missing input: legal context," floats a fog of jurisdiction tags (EU, California, Germany, Colorado) and open questions: Which laws apply? Whose jurisdiction? Is disclosure required? Is human approval needed? The stack has no input that answers them.

How It Works

Text version of this diagram

Three zones, separated by trust boundaries. In the enterprise, a human principal delegates to an AI agent, and an action context is assembled: identity and delegation, action and purpose, jurisdiction evidence, data categories. Inside UnGovr Nexus, three stages run in order: resolve nexuses (operator, principal, target, affected people, market, data), match versioned rules (regulated roles, effective dates, citations, with a human legal editor reviewing the rule corpus), and assemble the assessment (controls, uncertainty, decision class). Nexus informs, never authorizes. The assessment, with citations and a compact hash, crosses back to the enterprise: the policy engine (with its human approval checkpoint) combines it with organizational policy, the authorization server issues or refuses a narrowly scoped capability, the resource server independently enforces, and the audit log stores the assessment hash.

• Multiple nexuses, resolved independently. Operator, principal, target, affected person, market, and data location each attach law on their own. A hostname, TLD, or IP address is never treated as the answer.
• Versioned, reviewed rules. Assessments draw on UnGovr's jurisdiction-level AI-law research: primary-source citations, effective dates, regulated roles, and review dates. Rules are served only after human legal-editor review, and every assessment names the corpus version that produced it.
• Uncertainty is a first-class output. Conflicting rules are returned as conflicts. Missing material facts produce insufficient facts or human review required, never a guess.

A Worked Example

Text version of this diagram

A procurement agent operated by a US company acts for an employee in Germany, proposing a purchase order of 4,800 dollars on a supplier portal established in California, sending contact details from the EU to the US. Nexus resolves four nexuses: operator (US), principal (Germany, EU), target (California), and data (EU-to-US transfer). The assessment returns decision class controls_required with cited controls: disclose agent status, transaction cap review, cross-border safeguards; one unresolved fact (the supplier's terms are unknown); the corpus version; and a compact hash. The enterprise then decides: it grants a narrow capability limited to this supplier, capped at 5,000 dollars, expiring in one hour, with human approval logged and the hash stored in the audit record.

What Nexus Is Not

• Not a decision point. Nexus never returns legal or illegal. It returns context, controls, and uncertainty in one of four decision classes: context returned, controls required, human review required, insufficient facts.
• Not an authorization server. The enterprise policy engine combines Nexus attributes with organizational policy; an authorization server issues or refuses a narrow capability; the resource server independently enforces. Nexus is none of those.
• Not counsel. Nothing Nexus returns is legal advice or a substitute for qualified legal review.
• Not an oracle for delegation. Delegation evidence is echoed for your policy engine to judge, never certified.

Why Now

In February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, asking how agent systems can prove authority for a specific action, convey intent, handle delegation, enforce least privilege, and produce verifiable audit records. That architecture has identity providers, policy engines, authorization servers, and resource servers. It has no source for the legal dimension of an action. Nexus is a concept for that missing attribute source: intent arrives as a structured action context, controls give the policy engine material to narrow a capability, expiry times make context refreshable, and a compact assessment hash fits inside an authorization or audit event.

Community

Get Involved

We are looking for identity and authorization engineers, agent platform builders, and standards folks to pressure-test the contract: what attributes would your policy engine actually consume?

• Get involved at ungovr.org

Tech Stack