AI Agent Governance for Municipal Code Enforcement

Why Code Enforcement Requires More Than Generic AI Policy

Code enforcement is one of the more consequential functions a municipality automates with AI agents. Tasks such as inspection triage, violation detection, permit review, and citizen communication involve direct interaction with property records, permit databases, and personal contact information, and in some workflows can lead to formal enforcement actions against residents or businesses. This combination of sensitive data access and consequential output distinguishes code enforcement from lower-stakes AI use cases and means generic AI usage policies are insufficient on their own. What is needed is runtime governance: technical controls that govern what an agent can access, what actions it can take, and what record exists of what it did, enforced at the moment the agent operates rather than only through upstream policy documents.

Read Access Versus Write Access: The Core Risk Distinction

A useful starting point for governance design is separating what an agent is allowed to read from what it is allowed to write or execute. Read access covers data retrieval and triage functions, such as pulling parcel records to prioritize inspections or summarizing complaint history for a case. Write or action access covers functions that change state or trigger consequences, such as issuing a violation notice, updating a case status, or sending a formal communication to a resident.

These two categories carry different risk profiles. An agent with broad read access to citizen or property data beyond what a specific task requires increases exposure risk even if it never takes an action. An agent with write access that is not properly gated can take unauthorized or erroneous enforcement actions with real consequences for residents. Governance frameworks should treat these as separate permission tiers rather than a single access grant.

Identity and Permissions: Scoping Access Before Deployment

Agent identity should be distinct and attributable, separate from the human staff who configure or supervise the agent. This distinction matters for audit purposes: if an agent's actions are logged under a shared or generic account, it becomes difficult to reconstruct after the fact what the agent did versus what a human operator did directly.

Municipalities should also decide how granular identity scoping needs to be. An agent identity can be scoped per task (for example, a triage-only identity versus a notice-issuance identity), per workflow, or per deployment. Finer-grained scoping generally supports more precise permission enforcement and cleaner audit attribution, but adds administrative overhead in managing multiple agent identities. Before deployment, agencies should inventory which systems the agent needs (property records, permit databases, citizen communication platforms) and define least-privilege access per task type rather than granting broad standing access across all systems.

Tool-Call Governance and the Legacy System Problem

Tool-call restriction mechanisms constrain which external systems or APIs an agent can invoke and under what conditions, and this control should be separated from the model's underlying permissions. In practice, this means an agent's language model may be capable of generating a request to issue a citation, but the tool-call layer is what actually determines whether that request is permitted to execute, against which system, and under what conditions.

This separation allows enforcement decisions to be gated independently of model output, which matters because model behavior alone cannot be relied upon as a governance boundary. A practical complication in municipal environments is that legacy property, permit, and case management systems often lack native support for granular API-level access control. Where this is the case, a governance layer sitting between the agent and these systems becomes necessary to enforce tool-call restrictions that the underlying system cannot enforce itself.

Audit Logging and Public Accountability

Public accountability requirements in government operations generally mean automated decisions must be reconstructable after the fact, whether for a public records request, an appeal, or a legal challenge. This requires audit trail design to be deliberate rather than incidental. At minimum, a defensible audit record for an agent-driven decision should capture the input data the agent acted on, the rationale or basis for its recommendation or action, and the system state at the time of the decision.

Retrofitting this after an incident is materially harder than designing for it from first deployment, since the data needed to reconstruct a decision may not exist if logging was not in place when the decision occurred. Agencies should also consider that inconsistent enforcement outcomes across similar cases raise fairness and legal-exposure concerns distinct from typical AI governance failures, since code enforcement actions can carry financial or legal consequences for residents.