County AI governance still fails where runtime control begins

At a glance

What this is: This is an analysis of county AI governance maturity showing that policy adoption is rising, but runtime visibility and control still lag behind what AI systems are actually doing.

Why it matters: It matters because IAM, IGA, PAM, and AI governance teams cannot treat policy as proof when AI systems are already acting in production and may introduce unmanaged non-human identities.

By the numbers:

• 68% have implemented a countywide policy on artificial intelligence, according to the survey results.
• 59% have one on data governance, according to the survey results.
• 68.2% of counties report AI in threat detection and prevention, according to the Center for Digital Government.
• 74% had no manifest of the AI running across their organization, according to JetStream’s polling of National Association of Corporate Directors members.

Context

County AI governance is increasingly a runtime problem, not just a policy problem. A written policy can define intent, but it cannot prove what an AI system is doing once it is live, calling tools, and handling sensitive data.

That gap becomes more serious when AI is already embedded in operational workflows. The article frames the issue as a governance mismatch: organisations can adopt policy faster than they can establish discovery, ownership, and enforcement for the systems those policies are meant to govern.

For teams building AI oversight, the missing control is not another statement of intent. It is a mechanism for proving that live AI systems stay inside approved boundaries, especially when they begin to behave like governed AI systems.

Key questions

Q: What breaks when an organisation has AI policies but no runtime visibility?

A: Policy without runtime visibility leaves a governance gap between approved intent and actual behaviour. Security teams cannot prove what AI systems are doing, which data they touch, or whether tool use still matches the authorised scope. The result is compliance theatre rather than control, especially where AI already operates in production.

Q: Why do AI governance rules increase the importance of identity and access management?

A: Because AI rules depend on proving who approved use, who can change the system, and who can access the data it touches. IAM and IGA provide the audit trail for those questions. Without identity-linked ownership and entitlement control, organisations cannot demonstrate accountability when regulators request evidence of decisions or incidents.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: What is the difference between static policy and runtime control for AI agents?

A: Static policy states what the agent should be allowed to do, while runtime control determines what it can actually do at the moment of execution. For autonomous systems, that distinction matters because the security risk appears in live action, not just in configured permissions.

Technical breakdown

Why policy without visibility fails for AI governance

AI governance breaks down when policy is treated as the control instead of the control plane. A policy states permitted behaviour, but it does not discover new systems, show runtime usage, or confirm which data and tools an AI system can reach. In practical terms, the governance layer must know what exists before it can enforce what is allowed. That is why inventory, classification, and continuous monitoring are foundational, not optional. Without them, even well-written policy becomes an after-the-fact statement rather than an operational constraint. Practical implication: anchor AI governance to discovery and runtime telemetry, not to policy approval alone.

Practical implication: Treat AI inventory and runtime monitoring as enforcement requirements, not optional reporting.

How non-human identity changes when AI starts calling tools

Once an AI system can mint a key, access data, and invoke external services, it behaves like a non-human identity with real access scope. That means the system needs ownership, boundaries, and revocation paths just like any other machine identity. The important shift is that the identity is no longer static configuration. It becomes a governed runtime subject whose permissions, tool access, and data reach must be tied to a known purpose and accountable owner. Practical implication: classify AI systems that execute actions as governed identities, not just software features. See the Identity Governance for AI Agents Guide.

Practical implication: Assign ownership, scope, and revocation to AI-driven identities the same way you would for privileged machine accounts.

Why federated controls do not equal runtime assurance

MFA, IAM, and PAM improve the security baseline, but they do not by themselves prove that an AI system will remain within its approved use case after deployment. Federated access can authenticate the actor and still leave a large gap between authorization at setup time and behaviour during execution. That gap matters because AI systems can be reconfigured, repurposed, or extended faster than governance reviews catch up. The control problem is therefore not just who can sign in, but what the system can do after it is signed in. Practical implication: extend access governance into continuous runtime verification and revocation.

Practical implication: Use continuous verification to govern AI behaviour after authentication, not just at onboarding.

Threat narrative

Attacker objective: The practical objective is to exploit the gap between approved AI policy and uncontrolled runtime behaviour so the system can operate beyond governed boundaries.

1. Legitimate AI deployment begins with policy approval and a production rollout that creates a live operational footprint.
2. Once running, the system can call tools, access data, and act in ways that exceed what the written policy can observe or prove.
3. As the runtime expands, governance gaps emerge because discovery, ownership, and enforcement lag behind the system’s actual behaviour.
4. The impact is unmanaged AI activity that can affect services, data handling, and accountability without a reliable control point.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy-led AI governance is incomplete because policy does not become enforcement by itself. Counties in this survey show that written rules are now common, but rules do not reveal what AI systems are doing after they go live. That gap matters more than policy adoption rates because the control problem sits at runtime, not at drafting time. Practitioners should treat policy as a governance input, not the governance outcome.

Runtime visibility is the real dividing line between AI oversight and AI theatre. The article makes clear that organisations can have a policy, yet still lack discovery, inventory, and live enforcement. That is a governance failure mode, not a maturity nuance. The named concept here is runtime governance gap: the distance between documented intent and operational control once AI starts acting inside production systems. Teams should measure that gap directly.

AI systems that call tools should be governed as non-human identities, not as passive software. Once an AI can mint keys, access data, and invoke services, the access problem changes shape. Ownership, revocation, and scope boundaries become identity questions, not just application settings. The implication is that IAM and NHI programmes need a common model for AI systems that behave like actors, not assets.

Identity controls are necessary but insufficient unless they extend into continuous behaviour checks. MFA, IAM, and PAM establish a baseline, but they do not prove that an AI system remains inside its approved role after deployment. That is why runtime enforcement is now the control boundary that matters. Practitioners should design governance so approval, access, and ongoing behaviour are all measurable in the same programme.

County governance is moving toward evidence-based AI control, and that shift will spread beyond the public sector. The procurement logic is clear: if a system can operate at runtime, then the organisation needs proof that it stayed inside its approved boundaries. This is where AI governance starts to converge with auditability and lifecycle control. Security teams should expect the next question to be not whether AI is allowed, but whether it can be accounted for continuously.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Governance Guide

What this signals

Runtime governance gap: written AI policy is not the same as enforceable AI control. Counties can adopt policy quickly, but that does not tell security teams whether live systems are still behaving inside approved boundaries once tools, data, and external services enter the workflow.

The next governance step is to close the distance between approval and operation. That means AI discovery, ownership, and runtime enforcement need to be treated as a single control problem, not three separate projects.

For programmes already building AI oversight, the practical shift is from documentation to evidence. If a system cannot be inventoried, monitored, and stopped in operation, it is not fully governed.

For practitioners

• Define the AI inventory boundary List every AI system in scope, including internal tools, embedded features, and externally hosted services that can act on organisational data.
• Tie each system to an owner Assign one accountable owner for approval, monitoring, and retirement so every AI system has a clear governance path.
• Separate policy from enforcement Require runtime controls that can verify and restrict behaviour after deployment, rather than relying on policy documents alone.
• Test for shadow AI exposure Check whether teams can identify AI systems already in use without formal approval, especially in productivity and development workflows. See the AI Acceptable Use Policy Template.
• Build evidence into procurement Ask vendors how the organisation can prove a live AI system stayed within its approved boundaries over time, not just at sign-off.

Key takeaways

• County AI programmes are moving faster on policy than on operational control, which leaves a gap between written intent and live behaviour.
• The article shows that AI is already embedded in operational workflows, so discovery and ownership are now governance requirements, not future enhancements.
• Security teams should treat runtime enforcement as the proof point for AI governance, because policy alone cannot demonstrate what a system actually did.

Related NHI Mgmt Group resources: AI Governance Guide · Agentic AI Security Policy Template · Identity Governance for AI Agents Guide · AI Governance Platform Buyer's Guide

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.