Who is accountable for secure authorization when AI agents and MCP servers start accessing enterprise data?

Security and platform teams are accountable for putting authorization controls in place before AI systems and MCP servers are exposed to sensitive data. That means defining least-privilege access, validating request scope, and logging decisions for review. If official controls are missing, teams should assume others will build around them in unsafe ways.

Why This Matters for Security Teams

When AI agents and MCP servers can reach enterprise data, accountability shifts from the model prompt to the control plane that authorizes every tool call, token exchange, and data read. The practical risk is not just over-permissioned access. It is the speed and autonomy with which an agent can chain requests, reuse credentials, and cross boundaries that were never meant to be crossed. Current guidance suggests treating these systems as active workloads, not passive applications.

NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already acted beyond intended scope, including unauthorized system access and sensitive data sharing. That is why security teams cannot rely on informal ownership between app, platform, and AI teams. The authorization gap becomes visible only after an agent has already used a valid path into data that no one expected it to reach.

Practitioners should also read this through the lens of OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasize that the entity making the request must be governed at runtime, not just enrolled at onboarding. In practice, many security teams encounter unsafe agent data access only after a business owner has already connected the agent to production systems.

How It Works in Practice

Accountability should sit with the teams that own authorization policy, identity plumbing, and data exposure decisions, because those are the controls that determine whether an agent can act. For AI agents, static RBAC alone is usually too coarse. The agent’s behaviour is goal-driven and dynamic, so access needs to be evaluated at request time with context such as task intent, data classification, session provenance, and tool sensitivity. That is where policy-as-code and runtime authorization become essential.

A practical pattern is to issue short-lived, task-scoped credentials through just-in-time provisioning, then bind those credentials to a workload identity rather than a human account. For example, workload identity systems such as SPIFFE-style identities can prove what the agent is, while an authorization layer decides what it may do in that moment. Guidance from CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both point toward runtime governance, not one-time trust.

• Use per-task tokens or secrets with short TTLs, not reusable long-lived credentials.
• Check each MCP tool call against policy before the request reaches the data source.
• Log the decision, the requested scope, and the downstream resource for audit and incident response.
• Revoke access automatically when the task completes or the agent changes context.

NHIMG’s The State of MCP Server Security 2025 highlights why this matters: only 18% of MCP server deployments implement any form of access scoping for tool permissions, and hard-coded secrets remain common. These controls tend to break down when MCP servers are deployed as shared internal utilities because tool permissions and data scopes are reused across unrelated agents.

Common Variations and Edge Cases

Tighter authorization often increases operational overhead, requiring organisations to balance security against developer speed and tool availability. That tradeoff is real, especially in early-stage agent deployments where teams want broad access to prove business value. But broad access should be temporary, not the default. Best practice is evolving, and there is no universal standard yet for how to express agent intent in policy, so teams should document the local decision model and revisit it regularly.

One edge case is multi-agent workflows, where a planner agent delegates to specialist agents and each hop expands the attack surface. Another is MCP server sprawl, where a single compromised server can expose multiple tools, data sets, or credentials. In those environments, human-centric approval flows often fail because they cannot keep pace with machine-speed chaining. Security teams should align to OWASP Non-Human Identity Top 10 for credential and token hygiene, and use NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and auditability.

NHIMG’s OWASP NHI Top 10 and CoPhish OAuth Token Theft via Copilot Studio both reinforce the same lesson: if authorization depends on a static trust boundary, an agent will eventually find a path around it. In those cases, current guidance suggests treating every tool invocation as a fresh authorization event.

Related resources from NHI Mgmt Group

• Which control matters most when AI tools connect to enterprise data through MCP servers?
• Who is accountable when AI agents expose sensitive data through Jira MCP, and what controls should be in place?
• Who is accountable when AI agents expose sensitive Google Drive data through MCP tool calls?
• Why do AI agents accessing Salesforce through MCP increase data exposure risk?