Teams should treat those connections as access-bearing dependencies, not as ordinary integrations. That means approving them before connection, recording them in a registry, and validating what data they can reach and what actions they can trigger. If the dependency can modify enterprise state, it belongs in the identity governance process.
Why This Matters for Security Teams
When AI agents connect to third-party tools through MCP, the risk is not just integration drift. The agent can now discover, chain, and invoke capabilities without a human step at each action, which turns every connected tool into a potential access path. Guidance from the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both point toward stronger governance because static trust assumptions fail when the workload is autonomous and goal-driven.
That matters especially for MCP, where tool permissions can become broader than the original intent of the workflow. NHIMG research shows the scope problem is already real: in SailPoint’s AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope. In practice, many security teams discover overreach only after an agent has already touched data, triggered an action, or exposed a secret, rather than through intentional governance.
How It Works in Practice
The right response is to treat each third-party tool and MCP connection as an identity-bearing dependency. Start with registration: record the tool owner, data classes it can reach, actions it can trigger, and whether it can mutate enterprise state. Then require approval before connection, not after deployment. This is where current guidance suggests moving away from static role-based IAM toward intent-based authorisation, because the access decision should reflect what the agent is trying to do at runtime, not just what the service account was given months ago.
For high-risk actions, use just-in-time credential provisioning and short-lived secrets instead of standing credentials. An agent should receive the minimum token needed for the task, with automatic expiry and revocation when the task completes. That model is closer to workload identity than to traditional user identity, so cryptographic proof of the agent’s workload, such as SPIFFE or OIDC-based workload tokens, becomes more useful than a long-lived API key.
- Classify each MCP tool by data sensitivity and action scope.
- Enforce policy at request time with policy-as-code and contextual checks.
- Separate read-only tools from tools that can write, delete, or approve.
- Log every tool call with the agent identity, task intent, and output.
For broader framing, align the programme to the CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10, both of which reinforce least privilege, lifecycle control, and explicit governance for machine identities. NHIMG’s own coverage in the OWASP NHI Top 10 and the Analysis of Claude Code Security shows why agent tooling must be governed as execution authority, not just software integration.
These controls tend to break down when the MCP toolchain is embedded inside developer workflows with shared credentials and no separation between testing and production.
Common Variations and Edge Cases
Tighter MCP controls often increase friction, especially for teams that rely on rapid experimentation, so organisations have to balance developer speed against the cost of uncontrolled execution. There is no universal standard for this yet, but current guidance suggests that the more an agent can alter state, the more formal the approval and revocation model should be.
Read-only tools are the easiest case, but they still deserve registration and auditing because read access can reveal sensitive context or secrets. Write-capable tools need stronger controls, and tools that can approve, deploy, or purchase should be treated like privileged pathways. For those cases, ZTA principles from NIST Cybersecurity Framework 2.0 and the agent-specific recommendations in OWASP Agentic AI Top 10 are a better fit than inherited perimeter assumptions.
One common edge case is vendor-managed MCP infrastructure where the team cannot inspect the full tool chain. Another is multi-agent orchestration, where one agent delegates to another and the access path becomes indirect. In both cases, the same principle applies: governance must follow the action, not the wrapper. NHIMG’s reporting on the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign is a reminder that dependency trust can fail at the supply chain layer long before an agent misbehaves.
Where agents can self-discover tools, inherit tokens across sessions, or reuse secrets across environments, even well-designed policy often degrades because the real permission boundary is no longer visible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses tool misuse and unsafe agent actions through runtime governance. |
| CSA MAESTRO | TRM-02 | Maps directly to threat modeling for agent tool chains and delegated actions. |
| NIST AI RMF | Supports governance of autonomous AI behaviour and accountability. |
Model each agent-tool relationship and require controls for escalation, delegation, and data exposure.
