Allow Automation To Use Your Applications

KDCube users can now give their own scripts, agents, and DevOps jobs a bounded way to call KDCube. The feature is called Delegated Access — the Delegated by KDCube tab in Connection Hub: a signed-in user chooses resources and operations, creates a short-lived bearer token, and gives that token to automation. The automation does not become the user's browser session — it acts as a delegated client, while KDCube projects the approving user as the grantor.

user opens Connection Hub
        |
        v
Delegated by KDCube
        |
        | choose resource_grants + selected operations
        v
one-time bearer token
        |
        | Authorization: Bearer ...
        v
managed KDCube REST or MCP surface
        |
        v
application runs as grantor user, with delegated provenance

The bearer is a handle to a live Connection Hub card, not a frozen permission snapshot. Editing that card applies on the next call without reissuing the token; revoking it stops the bearer. Omitting account_scope during an update preserves existing account bindings, while an explicit empty map clears them.

One record shape: resource_grants

The important design choice is that the issued access record stores resource_grants, not separate resource and grant lists:

{
  "resource_grants": {
    "*/api/integrations/bundles/*/*/news@2026-05-20-12-05/operations/publish*": ["news:write"]
  },
  "operations": ["news_publish"]
}

That means grants are scoped to the resource they belong to. A token with {A: read, B: write} cannot use write on A. For admins, the all-resource case is also explicit:

{ "resource_grants": { "*": ["kdcube:role:super-admin"] } }

So an administrator can create a DevOps automation token for all platform and application APIs, while a regular user sees only the resources they are allowed to delegate.

This is different from connecting Gmail, Slack, or another provider account. Provider-account connections let KDCube call an external service for the user. Delegated Access lets a delegated caller — a script outside the platform, an external client, or an agent hosted inside a KDCube app — call KDCube for the user.

Everything the user granted lives in one place. The tab's Granted access list shows manual tokens, external clients that connected through the OAuth consent flow, and hosted agents the user granted with one click from a chat consent request or the capabilities picker — each entry badged by origin, with its approval time, per-resource access, and expiry. An agent's grants group into one card — everything that agent may do, each resource revocable on its own — and every Revoke cuts that caller off immediately.

For a manual named-services token, creation can narrow the exact namespace operations stored in the card. The backend update operation can replace that selection without reminting the bearer. The current existing-card UI preserves the nested selection but does not yet expose its picker, so that particular in-place edit is currently API-level.

Read the deeper article: Create Delegated Automation Access — the full model, the guard, admin all-resource tokens, configuration, and failure modes.

Allow Automation To Use Your Applications

One record shape: resource_grants

Related documentation