Agent Governance Card

RationaleEvery registry starts with a name. The UK's transparency standard (UK-ATRS field 1.1), the federal AI inventory (its use_case_name field), and the A2A technical spec (its name field) all open with one.

RationaleA short human-readable description. The UK publishes exactly this on its public (Tier-1) transparency sheet under UK-ATRS. Most agent registries fold "what it is" and "what it's for" into a single purpose field. The card keeps them separate for increased clarity.

RationaleThe EU AI Act requires this field (Annex VIII), and it's central to the research on making AI systems visible (Chan et al.). It's also the reference point several later fields are measured against, like whether the agent beats the old way of doing things, and whether it has drifted from its original job.

RationaleAdapted from the Cloud Security Alliance's (CSA) classification of agents. The type shapes how the agent proves who it is and drives much of the rest of the card. No registry captures this today: North Carolina's "Type of AI" field records the technique, and lumping everything into one "Agentic AI" box hides exactly the distinctions this field is built to draw.

RationaleThe A2A protocol's agent card declares the endpoint at which an agent can be reached, next to its name and provider. The Card demands the same thing. For a public-facing agent, this is the page where residents meet it; for an internal one, the application or endpoint staff use.

RationaleNo current register or standard has a capability field. The A2A protocol lets an agent describe its own skills in free text, so no two agents describe them the same way. The card uses a fixed list of seven, its own, so that capability can be compared across states. Information and drafting: answers questions, summarizes, drafts text for a person to use. Official communication: sends messages to residents or other parties in the government's name. Business transaction: completes an administrative act: a payment, a booking, a filing, a record change. Computer use: operates other software through its interface. Code execution: writes and runs code. Data analysis: queries and analyzes datasets. Physical actuation: controls equipment or devices. A chat assistant with no tools is information and drafting only.

RationaleThe fixed list above ensures comparability. This field provides the details.

RationaleThe EU AI Act requires an agent's "operating logic" (Annex VIII), and UK-ATRS gives the model its own sheet. The version matters as much as the name: a state that cannot say which version is running cannot monitor the agent or answer for its behaviour later.

RationaleHosting defines whose security perimeter the agent sits in and whose logs a reviewer can demand. The platform defines what the agent can be given access to and what leaving would cost.

RationaleThe federal AI memo (OMB M-25-21, §5) defines "high-impact AI" and lists the areas it covers: rights, access to benefits and services, health and safety, critical infrastructure, strategic assets. The card asks that question word for word. The card also carries the memo's rule that a human reviewing the output does not lower the impact (§4(a)), because that is the most common reason teams give for a lower answer. A team that has not made the determination yet picks "Not yet determined": the card completes with a provisional level that rises to High if the determination later says so, and making the determination goes on the to-resolve list.

RationaleRequired whenever you step down from a purpose that started out presumed high-impact. The federal AI memo (OMB M-25-21 §4(a)) requires an appropriate agency official to document that in writing. Without it, the most consequential legal judgment on the card leaves no trace for a reviewer or ombudsman to follow.

RationaleData-and-PII fields converge across UK-ATRS, CA-AIA, EU Annex VIII, and the federal inventory. The card asks for the most sensitive data the agent touches while operating, including what users type or say to it — which is not the classification of the knowledge base the agent was built on. For instance, an agent that answers questions from public documents but receives a user’s case details during user interaction handles personal data. The answer impacts the Impact Level.

RationaleThe sensitivity class in 3.1 names a ceiling; this field names the datasets under it. The UK standard records operational data on its own sheet. Research on governing agents (Nannini et al.) treats the inventory of what an agent can read and write as the starting point for every other control. A reviewer needs the names to check the classification, and a resident needs them to know where the agent's answers come from.

RationaleThe list of everything the agent can call or act on. The Cloud Security Alliance's identity framework requires agents to declare their capabilities and keep to a defined perimeter. The MCP specification describes agents' access as a set of tools and resources. The delegation literature calls this the agent's resource scope (South et al.). For software that acts, this list is the boundary of what can go wrong. No register written for earlier AI systems asks it, because a classifier or a chatbot has no tools to list.

RationaleThe highest level the agent reaches for any action it performs. The four levels are the card's own. They are inspired by the treatment of human oversight in US frameworks (NIST AI RMF, OMB M-25-21) and by the Cloud Security Alliance's autonomy tiers. “Informs” gives a user information but does not suggest what to decide or do, e.g. a case summary, an answer to "what documents do I need." “Recommends” proposes a decision, action, or ranking for a person to take: a draft eligibility determination, a "likely fraud" flag, a prioritized queue. The test is whether the output tells a user which way to go; if it does, the agent recommends, even when phrased as a draft. “Acts with approval” prepares an action that takes effect outside the conversation once a person confirms it: a pre-filled email sent on click. “Acts without approval” takes effect on its own: sends, files, updates records, pays.

RationaleCanada's Algorithmic Impact Assessment grades decisions by whether they can be reversed. The card asks the same question and fixes the moment to judge it: when the output reaches a person or a system that may act on it. What is judged is the effect on that person, not the artefact. A payment can be clawed back and a notice corrected, but the resident may already have spent the money or acted on the notice. "Fully reversible": nothing has left the system yet, or a built-in undo restores the previous state before anyone relies on it (a draft a person edits). "Reversible with effort": the output has reached someone and a separate corrective action can still undo the effect in time (a follow-up email, a corrected notice). "Hard to reverse": the effect cannot be fully undone by the state alone, whether or not the artefact can be recalled (a payment made, a decision communicated, a public post seen, a record deleted).

RationaleThe question asks for three facts that can be checked, and the value is read from them. The levels are anchored to concrete markers. “Negligible”: output stays inside the team, touches few people, no money and no rights involved. “Limited”: anything published outside the team or with a financial effect. “Serious”: wrong guidance that people can act on, or more than 10,000 people or records in reach. “Severe”: physical harm, the loss of a right, or an irreversible effect at scale. Concerns about what a model might do if it escapes its controls belong to the safety red-line (4.4) and the agentic hazards (5.2).

RationaleThree properties together make an agent dangerous without a person in the loop: it takes input it cannot trust (from the public or from an external system), it can read non-public personal or protected data, and it can change something outside the conversation. An agent with all three can be manipulated through its input into leaking or acting on protected data, with nothing to stop it. Based on the Spanish data-protection authority (AEPD) and Meta's "rule of 2" (via Nannini et al.). Three answers are possible. No. Yes, with compensating controls: all three are present, and the team names the controls that contain the risk; the level is at least Moderate. Yes, unresolved: all three are present and nothing contains them; the level is High, and the card recommends not entering production until one of the three is removed or controls are in place.

RationaleWork on autonomous systems commonly includes a way to stop them. Levels of Autonomy describes an off-switch at its top tier, Su et al. discuss safety interlocks, and the A2A protocol has task states in which work can wait or be cancelled. At High impact, the federal memo (OMB M-25-21, §4(b)) requires a fail-safe; the card asks for one that has been tested, not only described.

RationaleThe names come from NIST's generative AI profile (AI 600-1), which lists twelve risk categories; the card suggests the four that apply to nearly every government deployment: inaccurate or made-up output, harmful bias, data privacy, information security. The list is a suggestion, not a fixed set; a team adds what applies. Base risks are kept separate from the agentic hazards in 5.2 so that a plain chatbot or classifier can answer a short list and stop.

RationaleThis list draws on a survey of autonomy-induced attack surfaces (Su et al.) and on literature on multi-agent failure modes. These risks exist only when a system can act: prompt injection (instructions hidden in the content the agent reads), unsafe or irreversible actions, tools with more access than the task needs, poisoning of the agent's memory, and failures that cascade between agents. A system with no tools and no multi-step autonomy answers "not applicable", which is a complete answer. A system that only retrieves documents or web pages still answers: retrieved content is input the agent cannot trust, so prompt injection applies at minimum.

RationaleThe federal memo (OMB M-25-21, §4(b)) requires pre-deployment testing for high-impact AI, and Canada's Algorithmic Impact Assessment asks whether the system was tested. The card asks whether an evaluation of this system was carried out before deployment, and for the results. A completed impact assessment, a vendor's benchmark, or a checked box in a register is not an evaluation of this system. If none was done, the answer is No.

RationaleTransparency regimes ask whether a public description exists: the UK standard's public tier, Canada's publication of assessment results on its open government portal, the EU's public database. The card asks whether a plain-language summary of this agent is published, and where.

RationaleWhether people are told they are dealing with an AI agent is the question states have legislated first; Utah and California, among others, already require disclosure by statute. The card asks it of every agent that interacts with people, at every Impact Level, and asks how the disclosure is made. An agent used only by staff, with no contact with the public, answers "not applicable".

RationaleUK-ATRS records a Senior Responsible Owner explicitly as a role title, not a person's name. The card takes the same approach. A role survives staff turnover; when the person leaves, the responsibility stays with the position. North Carolina's AI inventory template asks for a named individual, which is the practice this field avoids.

RationaleThe EU AI Act's register requires the identity of the deployer; the federal AI use-case inventory is organized by agency and records a contact. The card asks for both, and makes the contact point public, following the UK standard's public tier. A published record that no one outside government can write to is not a transparency record.

RationaleLock-in is impact-independent. A low-impact pilot can still lock you in. For that reason every agent answers one line here: who the vendor is, or whether the system is built in-house, under what contract vehicle, and what leaves with the state if it switches. The full exit checklist from the federal AI procurement memo (OMB M-25-22) is in 12.3, for Moderate and High.

RationaleThe fifteen values are the federal AI use-case inventory's "Use Case Topic Area" list (OMB M-25-21), word for word. A state that uses the same list can compare its agents with federal use cases, and with other states, without translating categories.

RationaleThe four values are the federal inventory's "Stage of Development" list: pre-deployment (in development or acquisition), pilot (deployed in a limited test), deployed (in active use), retired (discontinued).

RationaleAn agent acts under some identity, and that identity impacts on who is accountable for the action. If it uses a staff member's login, the log shows that person acting; if it uses a shared account, the log shows no one. The Cloud Security Alliance's identity framework and the authenticated-delegation research (South et al.) favour giving an agent an identity of its own, and NIST's concept paper on agent identity explores the same question.

RationaleWork on agent identity ties the agent to a person: the Cloud Security Alliance requires a named sponsor and a chain of sponsoring principals, the delegation research (South et al.) ties the agent's credential to the user's identity, and NIST's concept paper on agent identity discusses linking agents to user identities. This field records who that person or role is. It differs from the accountable owner (6.1): the owner answers for the system, the principal is the person on whose behalf it acts.

RationaleThe delegation research separates what an agent is allowed to do (task scope) from what it is allowed to reach (resource scope). Written down together, the two describe the agent's authorization. The card asks for the description; the technical means of enforcing it are still being standardized, and this field does not require them.

RationaleThe Cloud Security Alliance has a rule of constrained delegation: no agent may give a sub-agent more privilege than it holds itself, and the creator of each agent is recorded. This field checks both, keeping the question practical, not hypothetical.

RationaleNIST's concept paper on agent identity asks how an agent's actions can be tied to a responsible person. The research on agent visibility proposes agent identifiers for a related purpose. This field asks for the mechanism that makes the trace possible, such as an identifier in the logs, not a statement that it is possible in principle. A Cloud Security Alliance survey reports that many organizations cannot yet clearly tell an agent's actions from a person's.

RationaleThe Part 1 autonomy answer (4.1) records the highest level the agent reaches. This field records the level for each type of action, so that "acts with approval" can be checked against a real list of what the agent does. The analysis of agents under EU law (Nannini et al.) suggest the boundary to be declared at this level of detail. For instance, a statement like "all financial actions require approval" is too coarse: it says nothing about the notification, the record update, or the flag on a case file that happen alongside the payment.

RationaleCanada's Algorithmic Impact Assessment requires human decision points at its higher impact levels; the Levels of Autonomy framework lets a user name the conditions under which an agent must stop; the A2A protocol has a state in which a task waits for further input before it continues (INPUT_REQUIRED). This field lists the actions that always require approval, whatever the context, as a summary of the "confirm_first" and "human_only" rows in 9.1.

RationaleChan et al. specify the log categories (tool use, reasoning, memory); Nannini et al. add the agent-native requirement — the log must distinguish what the agent initiated from what a person directed.

RationaleThe federal memo (OMB M-25-21, §4(b)) requires ongoing monitoring for high-impact AI. The research on agent visibility (Chan et al.) proposes real-time flagging of agent behavior, and the Cloud Security Alliance's framework proposes detecting when an agent's behavior departs from its declared intent. The card asks two things: whether monitoring exists, and what makes it raise an alert. A dashboard that no one is alerted by is not monitoring.

RationaleResearch on oversight structures in the public sector (Schmitz et al.) finds that reviewing an agent only at fixed points, such as launch or an incident, does not work, because the agent's behavior changes between those points; oversight of an agent usually needs to be continuous. This field records which of the three the deployment has. Continuous: automated monitoring runs all the time, with alerts (10.2). Periodic: a person reviews the agent's activity at a set interval, weekly or monthly for example; the interval is stated. Event-triggered: review happens only after a complaint, an incident, or a change. Periodic review is a common arrangement in government today, and recorded in North Carolina’s inventory approach.

RationaleThe federal checklist requires review by an office not involved in development. Canada's Algorithmic Impact Assessment requires more peer review as impact rises. This field records who performs that review here. In many deployments no such reviewer exists yet, and "not in place" is the answer that records it.

RationaleNannini et al.’s analysis of agents under EU law suggests a stated threshold that separates normal adaptation from a substantial modification of the system. Without one, a record stays unchanged while the system changes underneath it. This field names the threshold for this agent, for example a new tool, a new data source, a new user group, or a change in autonomy level, so that both the team and a reviewer know when the card is out of date.

RationaleAppeal fields converge across the federal memo (OMB M-25-21, §4(b)), the UK's Algorithmic Transparency Recording Standard, Canada's Algorithmic Impact Assessment. This field records the route for this agent: whom a person contacts, and what happens next. Many deployments have none, and "not in place" is the answer that records it.

RationaleThis field requires the record to name everyone affected, not only the users, building on Nannini et al. The recipient of an email the agent drafted is affected without ever having seen the agent; so is a resident whose case it flagged. This field asks for a list of who, not for an audience size — differently from North Carolina's inventory approach.

RationaleUK-ATRS carries this question as its GDPR Article 22 field. A person has the right not to be subject to a decision based solely on automated processing without a safeguard. This field records the safeguard that applies here, for example a right to request human review, a sampling audit of automated decisions, or an automatic hold on decisions above a threshold. If the agent never decides without review, the answer is "not applicable".

RationaleUK-ATRS's third-party block is the model for this field — supplier name, procurement procedure, and data-access terms as a discrete record. The federal inventory records the vendor name. This field takes the information-richer approach.

RationaleValue should be judged against the existing human process, not against zero (Schmitz et al.). This field records the comparison and the expected benefit. If the card is filled pre-deployment, this ensures that pilot results and, later, the renewal price can be measured against a stated baseline rather than a remembered one.

RationaleThe federal AI procurement memo (OMB M-25-22) lists what a contract must provide for an agency to be able to change vendors: transfer of knowledge, portability of data and models, transparency on licensing and pricing, rights to code and models produced under the contract, advance notice of changes on the vendor's side, and a plan for rollback and closeout. The card adds the agent-specific items under portability: prompts, interaction traces, fine-tuned models, and vector stores, which are the parts of an agent deployment that most often stay with the vendor. This field records, item by item, which of these the contract provides.