Notifications
Clear all
Topic starter
12/06/2026 9:38 pm
TL;DR: Access governance is being extended to OAuth clients, MCP servers, downstream connections, and AI agents, with enforcement at the token boundary and scope-level controls for OAuth connections, according to Descope. The broader lesson is that agent access needs policy decisions tied to identity, grant type, and downstream reach, not just authentication, because the trust boundary is now dynamic.
NHIMG editorial — based on content published by Descope: Descope Policies on granular access rules for agents and more
Questions worth separating out
Q: How should security teams govern agent access at the token boundary?
A: They should decide authorisation when the token is issued or exchanged, not after the agent already has access.
Q: Why do grant types matter for machine identity governance?
A: Grant types matter because they express whether access is autonomous, user-steered, or brokered through another client.
Q: What breaks when a policy engine does not distinguish connections from resources?
A: Teams lose the ability to control both the doorway and the payload.
Practitioner guidance
- Define token-bound governance points Inventory where tokens are issued, exchanged, and cached for agents, clients, and downstream connections.
- Split autonomous and supervised flows Create separate access policies for client credentials and user-present grant types so read-only machine activity cannot silently inherit write or execute scopes.
- Restrict downstream reach by connection and scope Treat OAuth connections, API keys, and certificates as distinct control objects and grant only the smallest reachable scope needed for each resource or MCP server.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact policy condition keys available for user, tenant, JWT, and client matching
- The illustrated examples for OAuth connections, API-key connections, and certificate-based connections
- The specific grant-type combinations used to separate autonomous access from supervised access
- The MCP server token-exchange pattern that turns one client into the only allowed doorway
👉 Read Descope's policy update for agent, client, and connection access control →
Granular agent access rules: are token-bound controls keeping up?
Explore further
12/06/2026 11:50 pm
Token-bound access is the real control plane for agent governance. Once AI agents and machine clients can trade tokens for downstream reach, the organisation is no longer governing login events alone. It is governing the moment authority is minted and exchanged, which is where overbroad access usually escapes review. The implication is that IAM teams should treat token issuance as a first-class governance boundary, not a technical afterthought.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many policy decisions are still being made with incomplete identity inventory data.
A question worth separating out:
Q: Who should be accountable when an agent can act with and without a human present?
A: Accountability should sit with the team that owns the policy model, because the risk changes when a human is absent. Autonomous access should be narrower than supervised access, and the policy should make that difference explicit. If the same entitlement applies in both cases, accountability is blurred and privilege creep becomes hard to challenge.
👉 Read our full editorial: Granular policy rules for agents expose the limits of token-bound access
