Council Post: A Technical Blueprint For Zero-Trust AI Access To Public-Sector Data
Gopichand Mannava, Independent Researcher, Enterprise Data and Analytics Architect, State of Connecticut.gettyAgencies are moving fast toward letting AI agents query government data directly; not just render da...
Gopichand Mannava, Independent Researcher, Enterprise Data and Analytics Architect, State of Connecticut.
getty
Agencies are moving fast toward letting AI agents query government data directly; not just render dashboards for humans to read, but retrieve records, summarize case files and flag anomalies on their own.
A federal IT leader survey found more than two-thirds of agencies are already piloting or implementing agentic AI, and nearly 90% said they require logging and audit trails for every action an agent takes. That last number matters more than it might seem. Most existing access-control architectures were never designed to satisfy it.
Having spent over a decade designing data governance architecture for large public-sector systems, I want to lay out, at a technical level, why conventional role-based access control (RBAC) breaks down for agentic AI, and what a more defensible architecture actually requires.
Why RBAC Wasn't Built For This
Traditional RBAC grants a user a role, and the role determines what tables, rows or reports they can see. It works reasonably well when the entity making the request is a human sitting in front of a dashboard, and it fails in three specific ways once the requester is an AI agent.
1. RBAC evaluates access at query time based on a static role assignment.
It has no native concept of why a request is happening, what task the agent is executing or whether the data being requested is proportionate to that task. An agent with a broad role can retrieve far more than a given task requires, and the system has no mechanism to flag that.
2. RBAC doesn't compose well across chained agent actions.
If "Agent A" retrieves a dataset and passes a derived summary to "Agent B," the access boundary that applied to Agent A's original query doesn't automatically travel with the derived output. The sensitive constraint gets lost at the handoff.
3. RBAC's audit trail records who accessed what.
It does not record why, under what policy or with what model version. For a human user, "user X viewed report Y" might be sufficient. For an agent making an autonomous recommendation about a benefits eligibility determination, it isn't.
A Technical Alternative: Policy-Evaluated, Attribute-Based Access
The more defensible pattern is attribute-based access control (ABAC) enforced at the semantic layer, combined with additional components RBAC doesn't have.
Dynamic Policy Evaluation
The access decision itself should be evaluated per request against a policy engine, not a static role table. Each request carries attributes: the requesting agent's identity, its assigned task, the data classification it's touching and the human principal on whose behalf it's acting.
The policy engine evaluates those attributes against declarative, policy-as-code rules (such as Rego/OPA) rather than a hardcoded permission matrix. As a result, policy changes become auditable, versioned and managed independently of application code.
Purpose-Bound Data Flows
Purpose binding needs to travel with the data. When an agent retrieves a record for a specific task, that task context should be attached as metadata to any derived output, so a downstream agent or process inherits the same access constraint rather than starting from a clean slate. Without this, a sensitive constraint applied at the first hop silently disappears by the third.
Decision Provenance
Every decision needs a provenance record, not just an access log. That means capturing which model version made a recommendation, what data and policy version informed it and what human approved or overrode it, written to an append-only, tamper-evident ledger rather than a mutable application log. This is the difference between "the system flagged it" and being able to reconstruct, a year later, exactly why.
Proportional Data Access
Finally, the policy engine needs a proportionality check, not just a yes/no gate. A useful pattern is scoping agent queries to the minimum field set the declared task requires, rather than granting table-level access and trusting the agent to only use what it needs. If an agent's task is "summarize case status," it shouldn't have a query path to full case notes containing unrelated protected information.
What This Buys You
None of these four components is exotic in isolation. Policy-as-code engines, metadata propagation, append-only ledgers and field-level scoping are all established techniques. What matters is combining them into a closed loop where every agentic data access is evaluated against declared purpose, constrained to proportional scope and permanently traceable, rather than bolting audit logging onto an access model that was never designed to answer "why" in the first place.
The Stakes
As agencies move from AI-assisted reporting to AI-initiated action, an access model that can only say who touched what (not why, under what policy or with what accountability chain) isn't a governance gap. It's the specific failure mode regulators, inspectors general and courts will be looking for first.
Agencies that rebuild their access architecture around purpose, proportionality and provenance now will be the ones prepared when that scrutiny arrives.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?