AI agent governance: civic identity and jurisdiction

Where a person performs dozens of actions a day, an AI agent can perform thousands of retrievals, tool calls and decisions, and controls designed for the first scale may not hold at the second. That is why AI agent governance in Digital-World Urbanization (DWU) treats each agent as an inhabitant with civic identity, meaning a verifiable identity of its own, a declared role, a jurisdiction, least-privilege permissions, an accountable sponsor, an activity record and a revocation mechanism someone can actually execute.

Northstar Consumer Group, the fictional manufacturer and retailer behind every example in this series, has a purchasing agent with none of that. It prepares purchase orders using credentials inherited from a developer, so the audit trail attributes its queries to that person and its permissions are the developer’s. The temporary analytics assistant used in collections is in the same position.

It’s the most technical post in the Digital urbanization series. The civic profile it works through comes from the section of my preprint (Rodas López, 2026) on agents, where it remains a proposal without empirical validation.

What a borrowed credential breaks

If an auditor asks who created a draft order for a new supplier in the middle of the night, the log will point to a developer who was asleep at the time. The inherited credential breaks attribution, and it breaks scope too. The developer has, for good reasons, permissions the task doesn’t need (test environments, repositories, maybe broad read access to ERP tables), and the agent inherits all of them, because least privilege is measured against a task and this agent never had a declared one.

Revocation is worse. Disabling the developer’s account shuts down the agent and locks out the developer, and if the credential was copied into a config file it may not even stop the agent. When the developer leaves the company, offboarding will shut the agent down without anyone in Supply chain knowing why.

Someone will propose a shortcut. Northstar has a shared service account, svc-integracion, used by several integrations, and moving the agent there looks like progress because it detaches the agent from a person. Attribution goes from pointing at the wrong person to pointing at nobody, and scope becomes the union of whatever every integration on that account needs.

Why controls built for people fall short

A typical enterprise’s access controls assume a human pace. Periodic recertification relies on the manager who signs it knowing what the employee does. Per-transaction approval assumes someone reads what they approve. And there’s a control nobody designed, the person who notices that a number “looks off” and stops.

With an agent, those assumptions weaken. Nobody can meaningfully recertify permissions for something whose task was never written down, and at agent density a per-transaction approval turns into a queue someone clears without reading. According to the paper, an agent’s actions can be context-dependent, probabilistic, tool-mediated and partially autonomous, so the same agent with the same permissions can decide differently when what it retrieves changes. I draw a rule of my own from that. An agent’s permissions should be sized for the worst it could do with them in an adversarial context.

Zero trust architecture (Rose et al., 2020) solves part of this, because it verifies each access to each resource explicitly and drops the assumption that an agent is trustworthy because it sits inside the network. That verification answers whether this identity may access this resource now. Civic identity places that access within a sponsorship, a jurisdiction and a purpose, which is what lets it answer the two questions an auditor asks after an incident, on whose behalf the agent acted and who is accountable for it.

The civic profile, field by field

The paper calls the set of attributes an agent carries into the enterprise its civic profile, and asks for it to be machine-executable where possible. Its fields include the assigned district (the business capability domain accountable for the agent), permitted buildings (the applications and services it may use), permitted zones of the subsurface, meaning the data products and knowledge bases described in the data subsurface, and approved mobility routes (the contracted APIs, events and queues from point-to-point integrations). The rest (identity, sponsor, autonomy, financial limits, human approvals, observability and revocation) mean what they say.

Under each group I noted the piece of public infrastructure (the shared identity, policy, audit and API services no system should rebuild on its own) that would enforce it, because a field no control point reads doesn’t constrain the agent.

Here is what the purchasing agent’s profile could look like, with field names of my own.

# Illustrative civic profile for Northstar's purchasing agent (fictional case).
# Not a standard, and not a schema defined by the paper.
civic_profile:
  id: purchasing-agent
  inhabitant_type: resident
  declared_role: prepare draft purchase orders for human review
  status: pilot               # proposed > pilot > production > suspended > retired
identity:
  issuer: corporate-identity-service
  class: workload             # its own identity, separate from any person
  credential: short-lived     # renewed by the issuer; never copied into config
  forbidden: [personal-credentials, shared-accounts]
sponsorship:
  sponsor: head-of-purchasing-entity-a
  district: supply-chain
  technical_team: purchasing-automation
jurisdiction:
  entities: [entity-a]
  data_residency: per-entity-a-policy
access:
  buildings: [erp.inventory-query, supplier-portal.read]
  data:
    reads:
      - supplier-master
      - purchase-history-entity-a
      - quotes-entity-a
      - gross_margin                  # Finance's data product
      - purchasing_knowledge_base     # where it retrieves the minimum-margin policy
    never: [employee-personal-data, margin-by-customer]
  routes:
    purchase-orders-api.v2: [create-draft]
    event.order-approved: [subscribe]
  tools: [find-supplier, request-quote, draft-order]
autonomy:
  level: prepare-and-propose
  human_approval:
    always: issue-order
    also_when: [new-supplier, amount-over-per-order-limit]
  financial_limits:
    per_order: set-by-finance
    monthly_total: set-by-finance
  delegation:
    allowed_to: [quoting-agent]
    max_scope: subset-of-this-profile
observability:
  log: [retrievals, tool-calls, drafts, delegations]
  every_event_includes: [sponsor, delegation-chain, jurisdiction]
  alert_on: [unapproved-route, foreign-jurisdiction, spend-near-limit]
revocation:
  who: [sponsor, security-operations]
  mechanism: disable-identity-at-issuer
  status_checked_by: [api-gateway, policy-engine]  # so live and delegated tokens fail too
  test: periodic-drill
review:
  cadence: set-by-sponsor
  on_sponsor_change: suspended-until-reassigned

The identity block is enforced by the corporate identity service I treated as a shared service in infrastructure before density. access, including its routes, becomes a set of policies that the gateway and the policy engine evaluate on every call, with jurisdiction (the legal entity whose rules apply) as an attribute, so a draft for entity B is denied even with a valid identity. Financial limits and human approval belong in the purchase order API itself and its workflow, because that’s where the amount lives. A limit only the agent knows about is a suggestion. With its own identity, the agent no longer goes down when the developer leaves. If the sponsor is the one who leaves, the last line of the YAML suspends the agent until someone accepts the handover.

Some fields no machine enforces. One person writes the declared_role and another judges it. A deployment check can confirm that sponsor points to an active person, and from there on, whether that person actually reviews what the agent does depends on their time and judgment.

Residents and visitors

A persistent internal agent with recurring responsibilities needs stronger lifecycle governance than a temporary analytics assistant. The framework calls the first a resident and the second a visitor. The purchasing agent is a resident in the making. Its tasks repeat, it accumulates versions and scope changes, and its sponsor will probably rotate before the agent retires.

The collections assistant is a visitor. Finance analysts use it to review overdue receivables for a bounded period, and its task doesn’t require writing to any system. Its profile can be much shorter, as long as it includes something the resident’s doesn’t need, an exit date.

# Illustrative visitor profile (Northstar is fictional; this is not a standard).
civic_profile:
  id: collections-analytics-assistant
  inhabitant_type: visitor
  declared_role: analyze overdue receivables for the current close
sponsorship:
  sponsor: head-of-collections
  district: finance
jurisdiction:
  entities: [entity-a, entity-b]
access:
  data:
    reads: [accounts-receivable]   # no writes to any system
  tools: [query, summarize]
  routes: {}                       # no routes with side effects
autonomy:
  level: read-only
  delegation: forbidden
validity:
  expires: when-analysis-closes    # a concrete date when the identity is issued
  renew: new-request-with-reason
  on_expiry: [revoke-identity, delete-working-context]

The underlying difference is the default. A resident exists until someone retires it, and a visitor only until the date its profile sets.

The typical risk is the visitor who stays, the assistant whose access gets renewed out of inertia until it has become a resident without ever going through a resident’s governance. That comes close to what the paper calls an informal digital settlement (a locally useful solution operating outside shared lifecycle controls), and the post on shadow IT covers what to do with those once they exist.

Delegation is subcontracting

When one agent hands work to another, the paper treats that delegation as subcontracting that must preserve traceable authority, with two limits. An agent can’t transfer permissions it doesn’t hold, and it can’t hide the sponsor on whose behalf it acts. Suppose, within the case, that the purchasing agent delegates quote comparison to a specialized sub-agent.

Technically, the sub-agent’s credential is derived from the agent’s. Its scope is the intersection of what the agent holds and what the task needs, its jurisdiction doesn’t widen, and it expires sooner. These, as an illustration, are the claims a delegated token might carry.

{
  "subject": "quoting-agent",
  "acting_for": "purchasing-agent",
  "sponsor": "head-of-purchasing-entity-a",
  "chain": ["head-of-purchasing-entity-a", "purchasing-agent", "quoting-agent"],
  "jurisdiction": ["entity-a"],
  "scope": ["quotes:read"],
  "expires": "before the purchasing-agent credential"
}

Rejecting an invalid delegation takes three mechanical checks. A requested scope that isn’t contained in the agent’s gets denied, and so does a chain that arrives without a sponsor or with a different one from the agent’s profile. And if the delegating agent has been revoked, everything derived from it stops being valid, which is what carries revocation down to the last link.

If the purchasing agent asked a supplier’s agent for quotes, the chain would cross the boundary of the territory, the scope within which Northstar has authority to set rules. DWU assumes that authority, and across organizations it would take institutional constructs the framework doesn’t develop.

What NIST and zero trust already cover

The paper presents the civic profile as a complement to AI risk management, and the table sums up how I read it against the frameworks it cites.

Model quality, bias, hallucination, prompt injection, data leakage and unsafe actions remain problems the profile doesn’t solve. What it does is locate them. If a supplier’s web page carries hidden instructions and the purchasing agent follows them, the profile bounds what the agent can achieve (a draft, in entity A, within the per-order limit, reviewed by a person) and records on whose behalf it happened.

The AI Agent Standards Initiative (NIST, 2026) is emerging work, and the paper asks for its own governance assumptions to be revisited against standards as they appear, so I expect the schema above to age quickly.

P4 and the comparison that matters

Proposition P4 in the preprint turns all this into a hypothesis. Enterprises that govern agents through district-bounded civic identities (sponsor, jurisdiction, entitlements and auditable lifecycle state) would have fewer authorization-related incidents, and attribute incidents faster, than enterprises that govern agents of comparable capability through centralized platform-level credentials of equivalent restriction.

What makes P4 useful is the comparison group. Against inherited credentials like Northstar’s, any control would win without telling us anything about civic identity. P4 measures it against an equally restrictive central credential. If that credential performs just as well, then sponsor, district and lifecycle state add nothing to least privilege, and that part of the framework is surplus.

If P4 holds, agent registries, audit events and incident records would show less time between detecting an improper action and knowing who answers for it, because the sponsor travels with the event. The rival explanation is serious. An organization able to maintain civic profiles probably also has more architectural maturity or stronger engineering talent, and the paper acknowledges the improvement could come from there.

Control against useful autonomy

The paper pairs P4 with a tension. Strong controls over agents reduce operational risk and limit useful autonomy.

At Northstar it would show first in human approval. The profile above requires a person to approve every order before it’s issued, which is prudent for a pilot and expensive once the agent prepares a lot of drafts, because the head of purchasing ends up approving in bulk without reading and the approval stops controlling anything. Grading it (always for new suppliers or amounts over the limit, sampling for the rest) would change the agent’s autonomy level, a risk decision someone in Finance has to sign.

Friction is another cost. If adding a tool means changing the profile, validating it and getting another signature, and the paperwork outweighs the value, the predictable response is a new “experimental” agent running once again on someone’s credentials. That’s the two-way relationship the paper describes between low habitability and informal settlements.

Sponsorship has a less visible cost. Someone has to agree to be listed as sponsor of something they didn’t build and whose behavior they can’t fully predict, and in my own platform work that signature was often the last thing to come through.

Who shuts it down, and how fast

Revocation is the test I trust most for whether an enterprise governs its agents. For every agent in production there are two questions with verifiable answers, who can shut it down and how long it keeps acting once the decision is made.

For Northstar’s purchasing agent, today’s answer is uncomfortable. Whoever administers the developer’s account can shut it down, and nobody knows how long that takes, because nobody knows how many tokens issued with that credential are still valid. In security for an API over SAP (in Spanish) I explained that an issued token stays valid until it expires and that, in that architecture, effective revocation depends on the authorizer’s cache, whose lifetime is in practice the revocation time. With delegation, that time adds up at every link that doesn’t check the status of whoever delegated to it.

In the first post of the series, the agent’s change sheet said revocation was immediate. I dropped the word here because nobody had measured it, which is why test: periodic-drill strikes me as the most important field in the profile. A drill in a controlled environment measures the real time, may turn up credentials nobody remembered, and makes the sponsor carry out a revocation personally at least once.

The framework doesn’t say how much time is acceptable between the order to shut down and the agent’s last act, or who sets that number, so each enterprise will have to decide it agent by agent. My suspicion is that it depends more on the agent’s financial limit and jurisdiction than on identity technology. The paper counts governance exceptions among the causes of urban debt, and an agent nobody has tried to shut down is one of them.