Why do coarse tool policies and OAuth scopes create risk for AI agents in data platforms?

Why coarse tool policy is riskier than it looks

Tool policy is only useful if it constrains the thing that matters, which is the data object or action hidden inside the request. In AI data platforms, a permissive “can call this tool” rule often becomes a weak proxy for real authorisation when the agent can pass free-text SQL, nested filters, JSON pointers, or indirect resource references. The control may look sound at the function level while still allowing a request to reach rows, documents, or tenants that should have stayed out of scope.

That mismatch matters because AI agents are not just clicking a UI, they are composing payloads. Once the platform accepts the call, the agent can sometimes shape the request in ways that bypass the human reviewer’s mental model of what is being accessed. The result is a classic authorisation gap, but hidden one layer deeper than ordinary API access. In practice, teams usually notice the problem only after an agent has already retrieved more data than intended, not during policy design.

How it fails inside data platforms

Coarse policies tend to fail in three places: request interpretation, scope translation, and downstream access enforcement. A tool policy might approve “query customer records,” but the actual payload could include a SQL fragment that joins to sensitive tables, a JSON path that resolves to a restricted object, or a connector reference that dereferences a broader dataset than the original call suggests. OAuth scopes can produce the same weakness when the token says the app may “read files” or “access CRM data,” but the platform does not distinguish between a harmless summary view and a highly sensitive object in the same namespace.

That is why the risk is not just overbroad access, it is semantic overbroad access. The policy grants capability at a level too coarse to express the real boundary. If the agent can generate or transform the payload, the boundary must be enforced where the payload is interpreted, not only where the tool is named. Stronger designs usually combine:

• object-level or row-level checks at the data layer
• narrow OAuth scopes tied to specific datasets or actions
• payload validation that rejects hidden expansion through SQL, nested references, or path traversal
• separate approval for read, write, export, and administrative actions

NIST’s security control catalog is useful here because it ties access control, configuration management, and auditability to the actual enforcement point, not just the nominal caller. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control structure practitioners can map to that enforcement design. These controls tend to break down when the platform treats the agent as a trusted application and never re-checks the object being reached.

Common variations and edge cases

Tighter tool and scope controls often increase engineering and review overhead, so teams have to balance flexibility against blast radius. That trade-off becomes sharper when agents must operate across multiple systems, because one coarse scope is easy to deploy but hard to defend, while many narrow scopes are safer but require better lifecycle management and clearer ownership.

There is also a practical difference between read-only and action-capable agents. A read path can still leak regulated or proprietary data, but a write path can also corrupt records, trigger workflow side effects, or create false audit trails. The same policy pattern may be acceptable for low-value summaries and unacceptable for source systems, especially when the agent can chain tools together. For that reason, current guidance suggests treating agent access as a data-governance problem as much as an API problem.

OAuth scope design is especially brittle when an integration is reused across environments or when a single token can reach multiple tenants, projects, or shared services. In those cases, the scope often describes the application more than the specific data boundary, which makes least privilege difficult to prove. OWASP API Security Top 10 is relevant because it frames broken authorisation as a structural API risk, not just an implementation bug. The pattern breaks down fastest in data platforms that let agents assemble queries dynamically from user prompts and then forward them without a second object-level check.

Risk and Threat Considerations

Coarse tool policies and broad OAuth scopes create privilege inflation, data exfiltration, and cross-boundary access risk. For AI agents, the danger is not only malicious abuse, but also accidental overreach when the agent follows a prompt in a way that expands the request beyond the intended object or tenant.

Failure mechanism: The agent obtains a valid token or tool approval, then uses flexible payload construction to reach a more sensitive object than the policy explicitly constrained. Because the platform authorises the call at the function or application level, the hidden data path is not re-evaluated at the point of access.

Impact: Sensitive records can be exposed, modified, or exported without a corresponding change in intended privilege. That can break tenant isolation, undermine audit confidence, and turn one compromised or misbehaving agent into a wide data access path.

Practitioner Guidance

What to prioritise: Put the control boundary at the object the agent can reach, not just the tool it can invoke. If the platform cannot express row, document, tenant, or action-level restrictions, treat the current policy model as too coarse for sensitive data access.

What to verify: Test real payloads, not just approved function names. Validate that SQL fragments, nested JSON references, and indirect resource lookups are checked against the same access boundary the user would expect, and confirm that OAuth scopes cannot be widened by an agent-generated request path.

Decision rule: If a token or tool permission can reach more data than the smallest unit of work the agent should perform, narrow the scope before expanding the agent’s autonomy. A broader scope is only defensible when the platform enforces object-level controls at runtime and logs the exact resource touched.

Practitioner takeaway: The safe design is not “trust the agent less,” it is “make the platform prove every data object the agent reaches.” If the access decision stops at the tool label, the real authorisation boundary is already too far upstream.

Related resources from NHI Mgmt Group

• Why do cloud data platforms create more governance risk when AI agents can query data at scale?
• Why do coarse OAuth grants and standing integration tokens create so much risk for AI agents?
• Why does session-level approval create risk when AI agents are allowed to use operational tools?
• Why do non-human identities create compliance risk even when policies exist?