Granular policy rules for agents expose the limits of token-bound access

At a glance

What this is: This is a product update about granular policy controls for agents, clients, resources, and connections, with enforcement occurring at token issuance and exchange.

Why it matters: It matters because IAM teams now have to govern machine and agent access at the point where tokens are minted, exchanged, and scoped, not only at login or registration.

👉 Read Descope's policy update for agent, client, and connection access control

Context

Token-bound authorisation is the control point that matters when applications, MCP servers, and AI agents can all request downstream access. If policy is only checked after a token already exists, the organisation has already accepted the trust decision too early.

The practical IAM problem is no longer whether an actor is authenticated. It is whether the actor, its grant type, and its downstream connection are constrained tightly enough that access cannot expand beyond the intended task, especially when a human is not present to narrow the scope in real time.

Key questions

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. That means mapping each client, connection, and resource to a specific policy path, then narrowing scopes by task, grant type, and context. This prevents broad tokens from becoming the default access wrapper for every downstream action.

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. If you do not separate those cases, the same identity can inherit the wrong privilege model. Treating grant type as an authorisation input helps teams keep routine machine activity distinct from supervised or delegated actions.

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. A connection may hold an API key or OAuth token, while a resource may expose specific scopes or grant types. If they are treated the same, privilege becomes too coarse and downstream access can expand beyond the intended workflow.

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.

Technical breakdown

Why token-bound policy enforcement matters for agent access

Token-bound enforcement means the policy decision happens when a token is issued or exchanged, not after the client is already operating with access. That matters for agents and machine clients because the token is the artefact that carries authority into downstream systems. If the token is too broad, the agent inherits reach that may outlive the task or exceed the request. This model is especially relevant for OAuth clients, MCP servers, and API connections because each may need different scopes, credential types, and grant paths. The architecture is essentially a gate on delegated authority, not a post-authentication audit layer.

Practical implication: map every agent and machine client to the exact token boundary where access should be decided.

How conditions narrow client, user, and tenant matching

Policy conditions let a rule target specific clients, users, tenants, roles, permissions, or JWT claims, and each additional condition tightens the match. That gives IAM teams a way to distinguish between a named client, a class of clients, or a user-driven flow without collapsing them into one broad rule. In practice, that matters for delegated access because the same client can behave differently when a human is present versus when it runs autonomously. Condition-based matching is therefore an authorisation filter, not just a label system: it determines who is eligible to request a token and under what operational context.

Practical implication: separate autonomous and human-driven access paths with distinct conditions and grant types.

Why grant type becomes part of the security model

Grant type is not a plumbing detail here. It becomes part of the authorisation decision because the same resource can be reachable through client credentials, authorization code, or token exchange with different privilege expectations. That distinction matters when a background worker should remain read-only unless a human is present, or when a downstream service should only be reached through a specific MCP server. By binding scope to grant type, the policy engine controls not only what is requested but also how the request is allowed to happen. That is a more precise model than assuming one identity can safely use one fixed access pattern.

Practical implication: treat grant type as an access control input and review each flow separately.

NHI Mgmt Group analysis

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.

Grant type now encodes trust level, not just protocol choice. A policy that differentiates client credentials from authorization code is doing more than selecting an OAuth flow. It is deciding whether an actor may act alone or only with an authenticated human in the loop. That makes the grant type part of the access model itself, which is exactly where machine identity governance needs to be more explicit.

Scoped downstream connections expose the difference between reach and entitlement. A connection that can hold an API key, certificate, or OAuth token should not be treated as a binary yes-or-no resource. The policy must decide whether the client can reach the connection at all, and then whether it can receive only the credential slice needed for the task. Practitioners should separate connection reachability from privilege size, because those are not the same control problem.

Human-in-the-loop controls only work if the autonomous path is genuinely narrower. The article’s split-policy pattern shows the right governance instinct: routine machine operation should not inherit the same privilege as a supervised action. That is not a product feature lesson, it is a programme design lesson. IAM teams should assume that human presence changes the acceptable risk profile and build separate entitlements accordingly.

From our research:

• 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.
• For a broader foundation on governance, lifecycle, and rotation, read Ultimate Guide to NHIs and then map policy enforcement to the identities you can actually see.

What this signals

Policy engines are becoming the practical layer where NHI governance meets agent behaviour. When a platform can distinguish client credentials from user-present flows, it creates the shape of a future programme in which access is defined by context, not just identity type. For teams building out machine identity governance, the next question is whether their inventory, approval, and review processes can support that level of precision.

With 97% of NHIs carrying excessive privileges in our research, broad machine access is still the default in many environments, and token-bound policy is one of the few ways to contain that drift at runtime. The governance problem is no longer simply provisioning access, it is proving that each downstream connection remains constrained to its intended use.

For practitioners

• Define token-bound governance points Inventory where tokens are issued, exchanged, and cached for agents, clients, and downstream connections. Assign an owner to each boundary so policy decisions happen before privilege enters the environment.
• 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.
• Review MCP server chokepoints If a downstream system should only be reached through one server, enforce token exchange rules so no other client can bypass that choke point.

Key takeaways

• Agent access governance now depends on policy decisions made at token issuance and exchange, not just on authentication events.
• Grant type, connection type, and downstream scope are separate controls, and teams that blur them will over-privilege machine identities.
• The safest operating model is to split autonomous access from human-supervised access and enforce narrower reach for the autonomous path.

Key terms

• Token boundary: The token boundary is the point where delegated authority is created, exchanged, or constrained before a client can act downstream. In machine and agent governance, this is the control point that determines whether access remains narrow enough to match the task.
• Grant type: Grant type is the OAuth flow used to obtain or exchange access, such as client credentials, authorization code, or token exchange. In identity governance, it matters because it signals whether access is autonomous, user-supervised, or brokered through another client.
• Downstream connection: A downstream connection is a protected service, API, or external system that stores or accepts credentials for later use by a client or agent. It is not just a resource target. It is the place where a token or secret turns into operational reach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Descope: Descope Policies on granular access rules for agents and more. Read the original.