Credential Policies

Credential policies — control allowed grant types, max TTL, allowed scopes, delegation depth, and required trust level at issuance time before runtime enforcement.

Credential policies let you define the operating envelope for an identity or key before a token is issued. Instead of making authorization decisions only downstream, you can prevent risky credentials from being minted in the first place.

What A Policy Controls

A credential policy can constrain:

• maximum token TTL

• allowed grant types

• allowed scopes

• required trust level

• required attestation level

• maximum delegation depth

That means policies are not just metadata. They participate directly in issuance decisions.

Why Policies Matter

Without issuance policy, an agent might:

• request a longer TTL than you want

• use a grant type you did not intend

• ask for broader scopes than its runtime role should have

• delegate deeper into a chain than your system can reason about safely

Credential policies give you a first control point before the token leaves ZeroID.

Example Policy

Python:

policy = client.credential_policies.create(
    name="orchestrator-production",
    description="Restrictive policy for first-party orchestrators",
    max_ttl_seconds=900,
    allowed_grant_types=["client_credentials", "token_exchange"],
    allowed_scopes=["data:read", "tickets:write"],
    required_trust_level="first_party",
    max_delegation_depth=1,
)

This policy means:

• tokens expire in 15 minutes or less

• only two issuance flows are allowed

• scopes are restricted to a known set

• only first-party identities qualify

• a single delegation hop is permitted

Choosing Good Defaults

For developer-facing open source adoption, these defaults are usually sane:

• short TTLs for interactive or tool-facing agents

• explicit allowed grant types

• explicit allowed scopes

• low max delegation depth until you have a reason to increase it

For production:

• prefer the smallest useful TTL

• do not allow all grant types by default

• gate sensitive identities behind trust-level or attestation requirements

Policy Design Patterns

Pattern 1: Local Development Policy

Use when developer friction matters more than strict enforcement:

• longer TTL

• fewer trust checks

• narrow but practical scopes

Pattern 2: Tool-Agent Policy

Use for narrow execution roles:

• very small scope set

• low TTL

• no further delegation

Pattern 3: Orchestrator Policy

Use for agents that coordinate sub-agents:

• moderate TTL

• allow token_exchange

• set explicit max_delegation_depth

Pattern 4: Sensitive Production Policy

Use where agents touch regulated or high-risk systems:

• short TTL

• required trust level

• required attestation

• minimal scope set

Example REST Call

curl http://localhost:8899/api/v1/credential-policies \
  -H "Content-Type: application/json" \
  -H "X-Account-ID: acct-demo" \
  -H "X-Project-ID: proj-demo" \
  -d '{
    "name": "tool-agent-default",
    "max_ttl_seconds": 600,
    "allowed_grant_types": ["token_exchange"],
    "allowed_scopes": ["data:read"],
    "required_trust_level": "first_party",
    "max_delegation_depth": 0
  }'

How Enforcement Works

At issuance time, ZeroID checks the request against the assigned policy. If the request violates the policy, issuance is denied before a credential is created.

That makes policies complementary to downstream authorization:

• policy decides whether a token may be minted

• downstream authorization decides whether the token may perform a specific action

You usually want both.

Common Mistakes

Avoid:

• allowing every grant type for convenience

• letting orchestrators delegate indefinitely

• using the same policy for orchestrators, tool agents, and background services

• relying on downstream checks alone while leaving issuance wide open

What's Next?

• Continue to Downstream Authorization to enforce what issued tokens can do.

• Revisit Token Flows if you are deciding which grant types to permit.