Give a Support Agent Access to One Customer's Records for 15 Minutes¶

A customer says their last three bookings have disappeared. Your support engineer wants an AI agent to inspect the booking history and explain what happened. The agent needs a small amount of access for a short job.

It's tempting to give it the support team's API key and put “remove access” on somebody's to-do list. That leaves the key able to do far more than this ticket calls for.

Let's make the permission match the job: read one customer's booking history, stop after fifteen minutes, and leave a record of who approved the access. This is an illustrative integration design using SigID's delegation APIs; the support application and customer in the example are fictional.

Write down the permission before choosing the API¶

Our support engineer is Maya. She can already inspect customer bookings in the support application. She opens ticket SUP-1842, selects customer customer_042, and asks the agent to investigate.

The approval should be specific enough that Maya can tell what will happen:

Allow the booking assistant to read this customer's booking history for ticket SUP-1842 until 14:15 UTC. It cannot change bookings or pass this permission to another agent.

The deadline starts when Maya approves. A retry or a new token must not restart the fifteen-minute window.

There are two kinds of permission to enforce. SigID handles the authenticated agent, the grantor, the token audience, delegated scopes, expiry, and the delegation chain. Your application knows what a booking is, which customer owns it, and whether Maya is allowed to authorize this investigation.

Calling a scope bookings:read doesn't teach an identity provider your database relationships. The customer boundary needs an application check.

Prepare a narrow integration¶

The application needs a configured SigID tenant, an OAuth client enabled for token exchange, and an active agent in that tenant. Maya also needs active membership and authority to approve access to the selected customer's records.

Configure an API audience and a bookings:read scope for that application. The scope is an example permission you define, not a built-in permission that every SigID account receives. It must be allowed for the application, present in Maya's grantor token, and marked delegatable for the exact audience.

For the examples below, assume the configured audience is https://support-api.example.com. Use the value actually registered for your API. The grantor token's audience must match it; editing a request's audience field cannot turn a token for a different application into authority for this one.

Maya authenticates through the hosted flow. Creation and revocation require fresh authentication and the assurance required by the route. If step-up is requested, complete it through hosted sign-in. Keep her token and the confidential client's credentials in the trusted backend. The agent runtime only needs the delegated token produced for this job.

The integration settings guide and agent authentication guide cover those prerequisites.

Create the delegation and bind it to the ticket¶

After checking Maya's access to customer_042, the backend creates a delegation using her bearer token at POST /api/v1/delegations. Here is the request body for an example approval at 14:00 UTC on September 13, 2026:

{
  "grantee_id": "11111111-1111-4111-8111-111111111111",
  "grantee_type": "agent",
  "audience": "https://support-api.example.com",
  "scopes": ["bookings:read"],
  "max_chain_depth": 0,
  "expires_at": "2026-09-13T14:15:00Z"
}

The UUID is a placeholder for the registered agent's management ID. Generate the actual deadline on your server from the approval time; the date above is only there to make the example concrete. Setting max_chain_depth to zero disallows sub-delegation.

The response gives the backend a delegation ID. Save it in an application-owned support grant with the ticket, customer, tenant, audience, exact deadline, and expected grantor and agent subjects. Resolve those subjects through trusted identity mappings for this audience. SigID uses pairwise token subjects, so the agent's management UUID and its token sub are different kinds of identifier.

Create this record through the approved server workflow. Don't let an agent submit an arbitrary delegation ID and customer ID to activate access. The record is the binding between Maya's approval and the resource being opened.

Keep the support grant inactive until both the SigID delegation and the application binding have been established. A partial failure must leave the agent without resource access. Retrying the setup should recover the same approval and deadline, not create another fifteen minutes.

Exchange authority for a token the agent can use¶

The trusted backend performs token exchange with Maya's token as subject_token and the agent's own token as actor_token. It requests the same audience and only bookings:read. The token-exchange guide contains the request format and client authentication details.

OAuth token exchange provides a way to request a new token using existing security tokens. The authorization server applies its policy to that request; the protocol is not permission to invent a broader grant. See RFC 8693.

In SigID, the delegated token identifies the acting agent in sub and carries the grantor context and delegation ID in act. This is the SigID claim profile your integration must follow. Don't assume sub is Maya because the agent is working on her behalf. The claims reference shows the exact shape.

Check that the returned token names the expected delegation before handing it to the agent. This avoids accidentally accepting another grant between the same principals. The agent's original login token must not be sufficient to use the support endpoint.

Check the customer on every read¶

The agent asks the application for:

GET /customers/customer_042/bookings
Authorization: Bearer <delegated-access-token>

First, the backend validates the token's signature, issuer, audience, tenant, expiry, required scope, and agent subject type. With the JavaScript validator, allowDelegation: true permits a token with an act claim; it does not require one or check the application's delegation policy. Perform those checks after validation.

The remaining decision can be expressed as pseudocode. These names describe application logic, not additional SigID SDK methods:

require a single grantor in the validated act claim; reject a nested chain
find the support grant by validated tenant, audience, and act.delegation_id
require that grant to be active and not revoked
require validated sub to match the grant's expected agent subject
require act.sub to match the grant's expected grantor subject
require the server's current time to be before the grant's fixed deadline
require the requested customer to match the grant's customer
require the approving engineer still to have access to that customer
read only bookings belonging to that tenant and customer
record the access decision without storing the bearer token

All of these checks precede the data read. If the grant store is unavailable, this endpoint cannot establish permission and must refuse the read. A write endpoint must perform its own authorization and reject this read-only grant.

The fixed application deadline matters even if the token is still accepted within a validator's clock tolerance. Token validity and permission for this particular support job have separate checks. A token minted at 14:14 does not move the grant's 14:15 deadline.

Let Maya stop the job early¶

Suppose the customer says they opened the wrong ticket. Maya presses “End access.”

The application marks its support grant revoked and enforces that state on subsequent requests. With Maya's appropriately authenticated grantor context, it also calls POST /api/v1/delegations/{id}/revoke. If that second operation fails, retain the local denial and make the outstanding revocation retryable with the required authentication.

SigID cascades delegation revocation to dependent delegations and bound token-exchange sessions. An external API that only verifies a JWT signature cannot observe that change on its own. The application grant check is what lets this support endpoint reject the next request without waiting for token expiry. Every serving instance must observe that revocation; an unchecked local cache would weaken the promise.

Ending access cannot retract records already returned or erase an agent's memory. This design authorizes individual reads. It does not promise to cancel a read already admitted or retract its response. If you need that stronger behavior, the data-serving path needs cancellation and response-boundary checks as well.

Try the requests the agent shouldn't make¶

Before offering the workflow to support, run these checks with test records. These are acceptance criteria for the illustrative application, not reported results from a deployed customer integration.

For each attempt, the application should record the ticket, customer, agent subject, grantor subject, delegation ID, request identifier, and decision. SigID's delegation audit records describe the authority lifecycle; your application records which booking data that authority was used to access.

Once the investigation is finished, Maya closes the ticket and ends the grant. The next support engineer can see who approved the access and which records the agent read. To implement this pattern, start with delegation and token exchange, then add the support-grant check beside your existing customer authorization.