AI agents that take actions: permissions, logging, and limits

Reference article · 5 min read

Most AI in agency use so far produces output for a person: a draft response, a summary, a suggested classification. A newer class of system acts. It updates a case record, sends a notice to an applicant, schedules an inspection, or advances a case to the next queue. The difference is not the model. It is that the software now holds credentials and writes to a system of record.

That shift moves the important controls from output quality toward access control. An agent that writes is a user of your systems, and it should be governed the way any privileged account is governed: a named identity, a short list of permitted actions, limits on how much it can do before a person intervenes, and a log that lets you reconstruct every action afterward.

What changes when a system acts

Mistakes persist. A bad paragraph is ignored. A bad write lands in the record and propagates to reports, notices, and other systems.
Speed removes the natural check. A person makes a few errors before someone notices. An agent can make thousands overnight.
Attribution becomes a real question. Staff, auditors, and the public will ask who changed a record, and "the system did it" is not an adequate answer.
Untrusted input becomes an attack path. Agents often read email, attachments, and web content, and text inside it can attempt to instruct the agent. The practical containment is not better prompting. It is that the agent cannot perform the requested action at all.

Give the agent its own identity

Do not run an agent under a shared administrator account or a staff member's login. Two patterns work.

A dedicated service account. The agent has its own identity with its own narrow permissions, and actions are clearly attributable to it. This is the usual default.
Delegated authority. The agent acts for a specific staff member and can never exceed that person's permissions. Useful where the system already enforces case-level access, but logs are harder to read unless the agent is separately identified.

In either pattern, scope permissions to the record types, fields, and status transitions the work requires, keep test and production credentials separate, store them in a secrets manager rather than configuration files, and rotate them.

Write down the list of permitted actions

Permissions in the source system are one layer. The agent needs a second, narrower layer: an explicit allowlist of actions, everything else denied by default, written as a document a program manager can read, not only as configuration.

For each action, state the object it touches, the fields it may change, the conditions under which it may run, and what happens on failure. Then decide which actions are never automated. Common candidates are denials and other adverse determinations, anything that releases records to the public, anything that moves money, and enforcement steps. Requirements vary by program and statute, so confirm that boundary with counsel.

Set thresholds and limits before go-live

Confidence thresholds. Below a set level, the item goes to a review queue instead of being acted on.
Severity thresholds. Route by consequence, not only by certainty. A routine status update and a change affecting eligibility do not deserve the same treatment.
Volume limits. Cap actions per hour and per day. At the cap, the agent stops and alerts a person.
Idempotency. Reprocessing the same item must not produce duplicate notices or duplicate records.
Reversibility. Prefer actions that can be undone, and capture the prior state so a reversal does not require a database restore.
A tested kill switch. One control that suspends agent writes without taking down the rest of the system. Test it before go-live and name who may use it.

Log everything, then actually read the logs

Each action should record the timestamp, the agent identity, the triggering event, the records consulted, the action taken and its parameters, the result, the model and configuration version in effect, and any human approver. Write the log where staff can see it next to the record, not only in a vendor console you cannot query.

Storage is not review. Read a random sample of automated actions on a fixed schedule, review every item that crossed an approval threshold, and reconcile agent-initiated changes against expected volumes. Treat these logs as records subject to your retention schedule, and assume they may be responsive to a public records request. Retention and exemptions differ by state and record type, so confirm treatment with your records officer or counsel.

What to ask vendors and require in the contract

Which actions can the product take, and can the agency disable individual ones without losing the rest?
What identity does it use in each connected system, and what is the minimum permission set it needs?
Are approval thresholds and volume limits configurable by the agency, or fixed by the vendor?
Is there an action log with the fields above, exportable in bulk through an API?
How are changes to prompts, models, or agent behavior released, and does the agency get notice?

In the contract, require configurable permissions and thresholds, agency access to complete logs during and after the term, advance notice before behavior changes, and cooperation on incident response if the agent acts outside its permitted list.

How to start

Run the agent in shadow mode first: it proposes actions, a person executes them, and you compare. Then pick one workflow with a bounded blast radius and a clear owner, enable writes for a narrow set of actions, keep thresholds conservative, and widen only when the review sample supports it.

HQT works with state and local agencies on integration, workflow, and AI systems, including permission design, logging, and review practices for software that takes actions.

Frequently asked questions

Should an AI agent use its own service account or a staff member's login?

Give the agent its own named service account in most cases, scoped to only the record types, fields, and status transitions its work requires. That keeps actions clearly attributable and lets you revoke the agent's access without touching anyone's staff account. Delegated authority, where the agent acts on behalf of a named employee and cannot exceed that person's permissions, is reasonable where the underlying system already enforces case-level access, but the logs must still identify the agent separately.

What actions should an AI agent never take without a person approving them?

Most agencies hold back adverse determinations such as denials and revocations, anything that releases records to the public, anything that moves money, and enforcement steps. Write the never-automated list explicitly rather than relying on the model to refuse, and enforce it in the agent's permitted-action configuration and in the source system's permissions. Because program rules differ, confirm the boundary with your program counsel before go-live.

What should we log when an AI agent updates agency records?

Log the timestamp, the agent identity, the event that triggered the action, the records and documents consulted, the action taken with its parameters, the result, the model and configuration version in effect, and the identity of any human approver. Store the log where staff can see it next to the affected record and where it can be exported in bulk, not only inside a vendor console. Then schedule an actual review of a sample, since storing logs nobody reads does not catch errors.

Are logs of AI agent actions public records?

Logs created and maintained by an agency in the course of business are generally treated as records, and agent action logs are no exception. Assume they may be responsive to a public records request and subject to your retention schedule, then handle any exempt content within them the way you would in any other system. Retention periods and exemptions vary by state and by record type, so confirm the treatment with your records officer or counsel.

How do we test an agentic system before it writes to production?

Start in shadow mode, where the agent proposes an action, a person carries it out, and you compare the two over a meaningful volume of real cases. Then enable writes for one workflow with limited blast radius, conservative thresholds, volume caps, and a tested kill switch. Widen the permitted action list only after your review sample shows the agent performing correctly on the narrower scope.