Who should be accountable for approving agent and MCP access policies?

Why This Matters for Security Teams

Accountability for agent and MCP access policies matters because these are not ordinary application permissions. Autonomous agents can chain tools, request data in ways humans did not anticipate, and persist far beyond a single user session. That means approval cannot be treated as a developer convenience or a one-off exception process. It has to be owned by the functions that can enforce policy consistently, accept risk formally, and revoke access when conditions change.

The risk is already visible in the field. NHIMG’s coverage of the State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, while 53% expose credentials through hard-coded configuration values. For agents, that kind of weak governance becomes a direct route to overreach, not just a hygiene issue. Guidance from the OWASP Agentic AI Top 10 also reflects this shift: approval must account for runtime behaviour, not only intended use.

In practice, many security teams encounter policy sprawl only after an agent has already accessed a tool, a dataset, or a secret that was never meant to be broadly available.

How It Works in Practice

The cleanest operating model is to separate policy authorship, business context, and technical enforcement. Security and identity teams should own the policy standard: what classes of agent or MCP server access are allowed, what requires formal review, and what is prohibited by default. Platform and application owners supply the operational context, such as data sensitivity, tool criticality, and downtime impact. The final decision should rest with a policy owner who can weigh risk consistently across teams.

For agentic systems, that approval model should be tied to workload identity and runtime context, not just a named human approver. Current best practice is moving toward short-lived, task-scoped credentials, with explicit evaluation at request time. NIST’s AI Risk Management Framework supports governance structures that assign accountability, while CSA MAESTRO agentic AI threat modeling framework is useful for mapping how an agent can abuse a chain of tools or permissions.

• Define a policy owner for each agent class and each MCP server, with clear approval thresholds.
• Use policy-as-code so approvals are evaluated consistently, not manually interpreted case by case.
• Require JIT credential issuance for high-risk tools, with automatic expiry after task completion.
• Review both the tool scope and the data scope, because MCP access often blurs those lines.
• Log who approved the policy, what evidence was used, and what revocation condition applies.

NHIMG’s OWASP NHI Top 10 and the CoPhish OAuth Token Theft via Copilot Studio analysis both show why approval must be operationally enforceable, not aspirational. These controls tend to break down in fast-moving platform teams where agents are created through self-service workflows and no one owns revocation.

Common Variations and Edge Cases

Tighter approval control often increases friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially when product teams want rapid experimentation with agents or MCP servers. Current guidance suggests using tiered approvals rather than a single universal gate, but there is no universal standard for this yet.

Low-risk internal agents may be pre-approved under a standard control baseline, while agents that can read customer data, trigger external actions, or access secrets should require explicit review from security and identity. In higher-risk environments, approval should also include legal, privacy, or compliance stakeholders when regulated data is involved. The OWASP Non-Human Identity Top 10 is especially relevant where the question is not just “who approved access,” but “who accepted the lifecycle risk of that identity.”

One important edge case is delegated admin. If a platform team can mint or widen agent permissions on demand, they may be operating as de facto approvers even if the formal policy says otherwise. Another is multi-tenant MCP infrastructure, where shared servers create cross-workload exposure and make accountability harder to trace. NHIMG’s reporting on the Ultimate Guide to NHIs highlights how quickly these identities become operationally sticky once they are embedded in workflows.

Where agent permissions can change dynamically at runtime, static approval workflows tend to lag behind actual behaviour and lose their value as a control.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent exposes sensitive Supabase data through MCP access?
• Who is accountable when identity teams let high-risk access remain ungoverned in cloud platforms?
• Who should be accountable for user access decisions when security, GRC, and auditors need the same evidence?
• Who is accountable when inappropriate data access is detected in an identity security program?