When an AI agent works a citizen's case, it acts with powers that the law gave to a named public official, and every step it takes may become a public record that a tribunal, an ombudsman or an archivist will later ask to see. Caseworker agents now triage benefit claims, chase evidence and update case systems. This guide answers three questions for casework agents: whose authority the agent uses, which of its prompts, outputs and actions are records, and how its contribution to a decision can be audited and challenged, with the identity and logging controls that make the answers provable. It is for public sector CISOs, service owners and records managers. The wider security picture for government AI, including deployment models and threats to citizen-facing chatbots, is in AI Security in Government and Public Sector; this page does not repeat it.
Source note: legal and records points summarise the cited official texts with status checked on 12 November 2026. Several are draft or recently amended, so check the current status with the issuing body. Confirm against the official text before relying on it.
Key takeaways
- Authority belongs to a named office holder, not the agent. Map every agent action to the power it supports, the delegation behind it and the accountable official.
- Agents prepare, officials decide, unless the law says otherwise. Automating a discretionary decision needs explicit legal authority and legal advice first.
- Agent material becomes a record when it is used. NARA's 2026 guidance says AI use alone does not create a federal record, but outputs used in official business do, and disposal needs an approved schedule.
- The audit trail must survive the agent. Log inputs, tool calls and identity, the draft and the human decision in a store the agent and its operators cannot alter.
- Citizens can challenge agent-assisted decisions. UK GDPR Article 22C, EU AI Act Article 86 and OMB M-25-21 expect information, human review and a route to contest.
Why casework agents are different
A casework agent touches the official file and the decision itself. What it can change drives the controls.
| Pattern | Typical tasks | Authority question |
|---|---|---|
| Assistive (read only) | Summarise a case file, find relevant policy, draft a letter for an officer to edit | None directly; the officer decides |
| Case preparation | Request missing evidence from the applicant, check eligibility rules, propose an outcome with reasons | The agent acts in the body's name when it contacts citizens |
| Case update | Write status changes, notes and tasks into the case management system | Write access to the official file under some identity |
| Decision support at scale | Score or rank applications, flag cases for fraud review or priority | Output may be the principal basis for a decision |
| Automated decision | Grant, refuse or vary an entitlement without a person deciding the individual case | Needs explicit legal authority to automate |
The risk is drift: a preparation agent whose proposals are approved without scrutiny is, in practice, deciding. The ICO's draft ADM guidance (updated 31 March 2026) asks whether there is meaningful human involvement; without it, the decision is solely automated and UK GDPR Articles 22A to 22D apply.
Delegated authority: whose power is the agent using?
Public law powers are conferred on office holders and delegated in writing to roles; an agent has no delegation of its own. The Commonwealth Ombudsman's Automated Decision-Making Better Practice Guide (March 2025) sets out the principle plainly: automation needs legislative authority for the decision and for automating it, the authorisation should nominate the position with ultimate responsibility, and agencies should not automate discretionary decisions until they have sought independent legal advice.
Map actions to powers
Build a decision rights register for each casework agent. One row per action the agent can take, with these columns:
- Action: the tool call, for example "send evidence request", "set case status to pending decision", "propose refusal".
- Power supported: the statutory provision or policy under which the outcome is made.
- Delegate: the role that holds the delegation, for example "Band 4 decision maker, benefits".
- Agent mode: complete, prepare only, or never.
- Enforced where: the case system permission, workflow rule or approval step that stops the agent going further.
The Ombudsman guide also expects the audit facility to report user access and decisions against delegations. For agents, that means the case system must be able to show that the person who approved an agent proposal held the delegation for that decision type on that date.
Identity design that preserves the delegation
| Design | What the logs show | Use when |
|---|---|---|
| Agent uses the officer's own session or password | The officer did everything | Never |
| One shared integration account for all agents | "svc_ai" did everything | Never for write access |
| Dedicated agent identity per agent role, acting alone | Which agent acted | Read-only preparation, back-office queues |
| Delegated token: agent identity plus the officer it acts for | Agent, officer and case together | Any agent that writes to the case file or contacts citizens |
The fourth design is the target. OAuth 2.0 Token Exchange (RFC 8693) lets a token carry both the acting party and the subject, so downstream logs record "agent X acting for officer Y". See the OAuth Token Exchange and Delegation Guide and, for multi-agent chains, the Delegation Chains and Attenuated Authority for AI Agents. The agent's authority must be narrower than the officer's: an officer may hold a refusal delegation while the agent may only propose one.
- Case binding: with short-lived tokens, see the Agent Identity and Access Guide; scope each agent session to the cases assigned to the officer or queue it serves, enforced by the case system, not the prompt.
- Write limits in the platform: status transitions the agent may perform (for example "awaiting evidence") separated from those reserved for delegates ("granted", "refused", "closed").
Records duties: which agent material is a record?
Records law is technology neutral, so the question is not whether a chatbot made it but whether the material documents official business. The US National Archives set this out in its Guidance on Applying the Federal Records Act to Artificial Intelligence Materials, issued with records management memo AC 11.2026 on 21 August 2026. It is a useful model outside the US too.
| Agent material | NARA position (summary) | Practical handling for a casework agent |
|---|---|---|
| Using an AI platform at all | Does not by itself create a federal record | Decide what is used; do not retain everything |
| Prompts | Likely records when captured in an agency system and circulated or used for official purposes beyond personal convenience | System prompts, task instructions and rule packs that shape casework are records of how the service works; version them |
| Outputs used in official business | Records, scheduled under whatever schedule applies to the resulting work product (an AI-created email follows the email schedule) | A drafted decision letter or case note that is used inherits the case file's retention |
| Audit trails | A trail kept inside the AI system is not automatically a record; it becomes one when captured and used for official business such as an investigation | For casework, you will use the trail to answer appeals and complaints, so plan for it to be a record |
| Disposal | Only under a NARA-approved schedule (General Records Schedule or agency schedule) | Agree the schedule before go-live; vendor default retention is not a schedule |
The NARA guidance does not address agent actions specifically. The cautious reading is that tool calls which change the case file, contact a citizen or shape a decision should be captured as records with the case. Elsewhere, assume under public records and freedom of information laws that an agent draft or log explaining a decision can be requested and must be retrievable. Logs contain personal data, so minimisation applies too. See AI Data Retention and Deletion and the Document and Records Management System Security Guide.
In the EU, Article 26(6) of the AI Act requires deployers of high-risk systems to keep the logs under their control for at least six months unless other law requires longer. National records law will usually require longer for casework.
Auditing agent decisions: what the trail must show
The Ombudsman's guide asks for an audit trail of the decision path that users cannot alter, and plain-English reasons covering the decision, material facts, that it is within power and how to challenge it. An agent trail must support that per case. Use the AI Agent Audit Log Schema Template as the base and add these public sector fields.
| Field group | Contents | Why a reviewer needs it |
|---|---|---|
| Case and authority | Case reference, decision type, power relied on, delegate who approved and their delegation reference | Shows the decision was within power and made by an authorised person |
| Identity | Agent identity, agent version, model and version, acting-for officer, token identifier | Separates agent actions from human ones |
| Inputs | Documents and records retrieved (with version or hash), citizen submissions read, rules and policy text applied | Reconstructs what the agent saw, including any manipulated upload |
| Actions | Each tool call, parameters, target system, result, time | Shows what the agent changed or sent |
| Proposal and reasons | The agent's proposed outcome and its stated reasons, as presented to the officer | Lets a tribunal compare the proposal with the final decision |
| Human decision | Accepted, edited or rejected; edits made; time spent; reasons recorded by the officer | Evidence of meaningful human involvement, or its absence |
| Notices | Whether the citizen was told AI was used, the explanation given, review route offered | Supports ADM safeguards and the right to explanation |
- Integrity: write the trail to an append-only store outside the agent platform that neither the agent nor its operators can edit (NIST SP 800-53 AU-9 Protection of Audit Information; AU-10 Non-repudiation where decisions must be attributable).
- Reasons from facts, not from the model's narrative: ground the statement of reasons in the logged evidence and rules, not the agent's summary. See the Explainable and Fair AI Guide.
What the rules ask for in casework
| Instrument | Status | What it means for a casework agent |
|---|---|---|
| OMB Memorandum M-25-21 (US federal) | Issued 3 April 2025; agencies had 365 days to document minimum practices for high-impact AI | Covers high-impact AI, whose output is a principal basis for decisions with significant effect, including on access to critical government services. Minimum practices include an AI impact assessment, human oversight with a fail-safe where practicable, and timely human review and appeal for affected people; non-compliant high-impact AI must be discontinued. See the US Federal AI Policy Guide. |
| UK GDPR Articles 22A to 22D, as amended by the Data (Use and Access) Act 2025 | In force; ICO guidance on the amended provisions is in draft (latest update 31 March 2026) | For solely automated decisions with significant effects, Article 22C safeguards: information about the decision, the ability to make representations, to obtain human intervention and to contest. See the UK Data Act 2025 Guide. |
| UK Algorithmic Transparency Recording Standard | Mandatory for government departments and arm's length bodies that deliver public or frontline services or deal directly with the public; recommended for the wider public sector | Publish a record of the tool and how it assists decisions. |
| EU AI Act Article 26 (deployers) | Annex III obligations apply from 2 December 2027 after the 2026 amendment | Oversight by people with competence, training and authority; public authorities use only systems registered in the EU database; inform people subject to Annex III decisions. See the EU AI Act Implementation Timeline Tracker. |
| EU AI Act Article 86 | Applies with the high-risk regime | People significantly affected by a decision based on a high-risk Annex III system's output can obtain clear and meaningful explanations of the system's role and the main elements of the decision. |
EU public bodies deploying high-risk systems also need a fundamental rights impact assessment; see the EU AI Act Fundamental Rights Impact Assessment guide. Australia's Royal Commission into the Robodebt Scheme (final report 7 July 2023) is the reference case for automated debt decisions at scale.
Threats that matter most in casework
The general threat picture is in the government AI guide; four threats change the casework design. Citizen submissions are untrusted content that can carry hidden instructions to mark evidence as verified (OWASP LLM01:2025 Prompt Injection; MITRE ATLAS AML.T0051.001 LLM Prompt Injection: Indirect). An agent that can both propose and commit, or edit payment details, turns one manipulated file into a wrongful payment or refusal (OWASP LLM06:2025 Excessive Agency; ATT&CK T1657 Financial Theft). Write access lets an agent alter case notes (ATT&CK T1565.001 Stored Data Manipulation), and queue-wide read access lets it pull another citizen's file into a letter (OWASP LLM02:2025; ATLAS AML.T0086). Stolen agent tokens are valid accounts for an attacker (ATT&CK T1078, T1528). Automation bias is the quietest threat.
Implementation: a phased rollout
- Inventory and classify: list every casework agent and agent feature in case management and contact centre platforms, with owner, identities, data and decision types. In US federal agencies this feeds the M-25-21 use case inventory; record it in an AI agent registry.
- Legal and records review before build: confirm the power for each decision type, whether automation is authorised, the delegations involved, the records schedule that applies to case files and agent logs, and the ADM, DPIA and transparency obligations. Run the DPIA and the AI impact assessment together.
- Design identities and limits: per-role agent identities, delegated tokens that carry the officer, case binding and platform-enforced status transitions, as in the decision rights register.
- Build the audit trail first: stand up the protected log store and per-case retrieval before the agent touches live cases; test that an appeals officer can reconstruct a decision.
- Shadow mode: run the agent on real cases without effect and compare its proposals with officers' decisions, including known-outcome scenarios led by the policy owner.
- Prepare-only go-live: the agent drafts and requests evidence; delegates approve every outcome.
- Widen carefully: completion only for non-discretionary, low-impact steps with legal authority; retest after every change.
- Rollback: a documented switch back to manual casework, a kill switch that revokes agent tokens, and a remediation plan for reopening affected cases if a systematic error is found.
Small bodies: a local authority using a supplier's case platform will rarely run token exchange itself. Put the requirements in the contract: separate agent identities, logs exportable to its own store, retention under its schedule, and an off switch that keeps the service running.
Detection and measurement
- Delegation mismatches: alert when an approver lacks the delegation for the decision type, or an agent token performs a reserved status transition.
- Scope breaks: agent reads of cases outside the assigned queue or officer caseload.
- Log integrity: gaps in the trail, failed writes to the protected store, or deletions outside the schedule.
| Metric | What good looks like |
|---|---|
| Share of agent proposals edited or rejected by officers | Stable and non-zero; a fall towards 0% suggests rubber-stamping |
| Median officer review time per agent proposal | Long enough to read the evidence for the decision type |
| Cases with a complete, retrievable audit trail | 100% of agent-touched cases |
| Agent actions attributable to an agent identity and an acting-for officer | 100% of write actions |
| Appeal and complaint overturn rate for agent-assisted cases against manual cases | No worse than manual; investigate any gap |
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Accountable roles and delegations | GV.RR-02 | AC-2, AC-6 | A.5.2, A.5.3 | Control 6 |
| Legal and records obligations | GV.OC-03 | PT-2, AU-11 | A.5.31, A.5.33 | Control 3 |
| Agent inventory | ID.AM-02 | PM-5 | A.5.9 | Control 2 |
| Scoped agent access | PR.AA-05 | AC-3, AC-6, IA-2, IA-5 | A.5.15, A.5.18 | Control 6 |
| Decision audit trail | PR.PS-04 | AU-2, AU-3, AU-9, AU-10 | A.8.15 | Control 8 |
| Monitoring agent activity | DE.CM-03, DE.AE-03 | CA-7 | A.8.16 | Control 8 |
Common failure patterns
- The agent borrows the officer's login. Agent actions look like the officer's, the delegation record is false, and nobody can say afterwards which steps a person took.
- Approval without scrutiny. Officers accept proposals in seconds, so the decision is solely automated in practice and the ADM safeguards were never designed in.
- Logs left in the vendor platform. Default retention expires or the trail cannot be exported per case, so an appeal cannot be answered.
- Weak access boundaries on public systems. The OpenAI agent Medicare portal incident showed an agent reaching non-public government files, with the root cause disputed between bypassed controls and a guest endpoint that required no credentials, and notification to the agency weeks after discovery. Enforce access in the system and agree incident reporting terms with agent suppliers.
- Reasons written by the model. Letters repeat the agent's summary rather than findings on the evidence.
Practitioner checklist
- Keep a decision rights register per casework agent: action, power, delegate, mode and enforcement point.
- Give each agent role its own identity, and use delegated tokens that record the officer it acts for on every write.
- Reserve outcome status transitions, payee changes and contact detail changes for authorised people in the case platform.
- Get legal confirmation before automating any discretionary decision, and record it.
- Agree the records schedule for agent outputs, prompts and audit trails before go-live; never rely on vendor default retention.
- Write the decision trail to a protected store outside the agent platform, retrievable per case.
- Tell citizens when an agent contributed, and give them a route to human review and challenge.
- Track override rate and review time to detect rubber-stamping, and retest after every rule or model change.
Standards and references
- OMB: M-25-21 Accelerating Federal Use of AI through Innovation, Governance, and Public Trust
- NARA: Guidance on Applying the Federal Records Act to Artificial Intelligence Materials
- NARA: Records Management Memo AC 11.2026
- ICO: What are the ADM safeguards? (draft guidance)
- GOV.UK: Algorithmic Transparency Recording Standard Hub
- EU AI Act: Article 26 Obligations of Deployers of High-Risk AI Systems
- EU AI Act: Article 86 Right to Explanation of Individual Decision-Making
- Commonwealth Ombudsman: Automated Decision-Making Better Practice Guide
Related NHI Mgmt Group resources: AI Security in Government and Public Sector, Public Sector Identity Security Guide, AI Agent Audit Trails for Regulators Guide, Dual control and four-eyes approval for privileged and agent actions. This guide summarises public law, records and AI rules and is not legal advice.