Identity

This capability is on the Roadmap; the API shown here is the planned design.

By default the gateway sees your service, not the person the agent is acting for. That is fine until policy depends on who is asking. DDK will let you run a block of agent code on behalf of a user:

async with donkey.as_user(id_token=slack_user_oidc_token):
    await hr_bot.answer(question)      # the gateway sees the user, not just the service

Inside that block, DDK acquires a user-scoped token via RFC 8693 token exchange and attaches it to every governed call, so the gateway’s Trusted Agent Identity layer can apply per-user policy. The exact token-exchange endpoint and header the gateway expects will be pinned to the gateway’s documented contract.

The problem this solves

An HR bot must not answer a manager’s salary question about a different manager’s report.

That decision belongs to the gateway — it is the component that holds the identity policy, the org-chart relationships, and the audit obligation. DDK’s job is to get the user’s token onto the request correctly so the gateway can make the call it is already able to make.

Where the boundary sits

No silent fallback

The failure mode to design against is a token exchange that quietly fails and lets the call proceed under the service identity. Per-user policy would stop applying while everything still appears to work.

So entering as_user() will either attach a user-scoped token or raise. It never degrades to the service identity without telling you.