Notifications
Clear all
Topic starter
02/06/2026 6:57 pm
TL;DR: Curity’s code examples include an OAuth-secured MCP server, backend agent authorization with A2A, and step-up authentication patterns that show how agent access must be constrained at the protocol and token level, not just at login, according to Curity. The security lesson is that AI agents introduce delegated access paths that need explicit approval, scoping, and revocation discipline.
NHIMG editorial — based on content published by Curity: code examples for securing API access, OAuth flows, MCP authorization, and identity server plugins
Questions worth separating out
Q: How should security teams govern AI agents that use MCP to access tools?
A: Security teams should treat MCP access as scoped, task-bound authorization rather than broad session trust.
Q: Why do AI agents create different IAM risks than ordinary service accounts?
A: AI agents can choose actions, chain requests, and escalate across tools in ways ordinary service accounts usually do not.
Q: What breaks when agent access is handled only through login controls?
A: Login controls do not govern what happens after the agent is in the environment.
Practitioner guidance
- Map every MCP tool path to an explicit authorization decision Document which requests require human approval, which can be delegated, and which must be denied by default.
- Apply step-up checks to high-risk agent actions Require stronger authentication or approval when an agent requests privileged APIs, cross-system writes, or changes to policy.
- Track plugin logic as part of the identity control plane Inventory every custom plugin that affects SSO, token issuance, or revocation, then assign control ownership and test cases.
The practical next step is to make every delegated agent action traceable to an owner and a decision record?
👉 Read Curity’s code examples for MCP authorization, SSO revocation, and OAuth flows →
Explore further
02/06/2026 7:12 pm
MCP authorization is becoming a first-class NHI governance problem. When agents connect through MCP, the security question shifts from whether the agent can authenticate to whether each tool invocation is properly authorized. That changes the control surface from single login events to ongoing, task-scoped access decisions. Practitioners should treat MCP as an identity-bound execution channel and govern it accordingly.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably prove who or what still has access.
A question worth separating out:
Q: How should organisations respond when privileged agent access must be revoked quickly?
A: They should be able to revoke the agent’s token, disable any related plugin path, and confirm that downstream sessions or delegated grants are also invalidated. The first priority is containment. The second is evidence, so the team can verify which actions were already taken and whether any scope persisted.
👉 Read our full editorial: MCP authorization and AI agent access control in Curity examples
