Tool-level control can still leave the backend database overexposed if the MCP server’s service identity has broad permissions. The model may only see approved tools, but the query it generates can still reach rows, columns, or actions that exceed the user’s entitlement. Real governance requires authorisation at both the tool surface and the data layer.
Where tool-level control stops and data-layer control starts
Tool-level access control limits which actions an agent can invoke, but it does not by itself constrain what the backend does with the privileges it already has. If the service identity behind the MCP server can query broad tables or perform privileged writes, the agent can still reach data and actions the end user should never see. That is the core mismatch: request mediation is not the same as enforcement at the resource.
In practice, the tool surface is only a broker. The real security question is whether the backend enforces the same entitlement boundary after the tool call is translated into SQL, API requests, or other data operations. If not, the tool can look safe while the underlying execution path remains overpowered.
That is why least privilege has to be expressed twice, once at the tool boundary and again at the data boundary. An agent that can only call an approved tool may still cause over-broad reads or writes if the tool’s service account, database role, or downstream API scope is not tightly constrained.
Why the backend can still overexpose rows, columns, and actions
The failure mode is a confused-deputy pattern. The agent acts within the allowed tool set, but the tool executes with broader authority than the caller should have received. If the backend does not bind the query or action to the requester’s effective permissions, the model can indirectly retrieve restricted records, modify protected objects, or trigger administrative functions.
This becomes especially dangerous when data access is coarse-grained. Table-level access, shared schemas, permissive stored procedures, and service identities with reusable credentials all widen the blast radius. Even a well-behaved model can generate a legitimate-looking request that lands on data the user is not entitled to access.
The practical lesson is that authorization must be preserved across translation layers. A safe tool list does not rescue an unsafe service identity, and a safe service identity does not rescue an unsafe query model. The control has to survive the full path from prompt to tool invocation to backend execution.
What governance needs to cover in agentic access paths
Governance should treat the agent, the tool, and the data store as separate authorization points. That means the tool should be allowed only to request a narrow set of operations, while the backend should independently enforce row, column, object, and action policy based on the effective user or approved delegation context.
Where possible, separate read and write paths, scope service identities per use case, and avoid a single shared database role for every agent action. In stronger designs, the backend receives a caller context that it can evaluate directly, rather than trusting the tool to have already made the correct access decision.
For agentic systems, this also means designing for denial, not just success. The system should be able to fail closed when the tool asks for a broader dataset, a sensitive field, or an unsupported action. Without that, the access model is only descriptive, not preventive.
Risk and Threat Considerations
When tool-level controls are not matched by data-layer policy, the main risk is silent privilege expansion. The user may appear to have limited access, while the backend identity can still expose sensitive records or execute higher-impact actions on the user’s behalf.
Failure mechanism: The agent sends a valid tool call, but the service identity behind that tool has broader database or API permissions than the initiating user, so the backend returns or changes data beyond the intended entitlement boundary.
Impact: This can produce data leakage, unauthorized updates, broken segregation of duties, and hard-to-detect abuse because the transaction looks legitimate at the tool layer even when it is excessive at the resource layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Tool and backend privileges must be minimized across both control points. |
| AC-3 — Access Enforcement | Row, column, and action checks depend on enforcing policy at the data layer. | |
| IA-9 — Service Identification and Authentication | MCP service identities are the backend authority that can overexpose data if too broad. | |
| Recommendation — Restrict service and user permissions to the minimum needed for each agent action. Enforce authorization on the resource actually being accessed or modified. Authenticate service identities tightly and scope their permissions to each backend use case. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Agent tools can expose higher-impact actions when backend function checks are missing. |
| API1 — Broken Object Level Authorization | The question centers on users reaching rows or objects they should not access. | |
| API3 — Broken Object Property Level Authorization | Column-level overexposure is a direct concern when the model can reach fields it should not see. | |
| Recommendation — Authorize each backend function independently of the tool that invoked it. Check object-level access on every request that touches backend data. Filter sensitive properties at the data layer before returning object payloads. | ||
Practitioner Guidance
What to verify: Confirm that the backend policy is evaluated on the actual rows, columns, objects, or actions being touched, not only on the tool name or endpoint. If you cannot explain how the effective user context reaches the data layer, the control is incomplete.
Decision rule: If the tool needs broad backend privileges to function, treat that as a design defect and narrow the service identity before expanding the tool rollout. If the backend cannot enforce per-request policy, the agent should not be allowed to reach sensitive datasets.
What good looks like: The tool can only request a bounded operation, the backend independently enforces policy, and any attempt to cross entitlement boundaries is denied with an auditable decision.
Practitioner takeaway: Agent governance is only real when authority is constrained at the interface and at the data source, because either layer on its own can still become a path to overexposure.
Related resources from NHI Mgmt Group
- What breaks when AI agents are allowed to access agreement data without redaction or inspection at the tool layer?
- What breaks when LLM access control is limited to application code instead of a central policy layer?
- What breaks when access control is weak on agent metadata, tool inventory, or execution endpoints?
- What breaks when access control stops at the MCP tool layer?