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 session selects an exact Connection Hub card by access_id; it is not a frozen permission snapshot. Every invocation resolves the current durable card under the active catalog. Editing or revoking that card applies on the next invocation without reissuing the token; work already admitted may complete. 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. Every Revoke advances durable lifecycle state so the next invocation is denied.

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 existing-card UI renders the same catalog-aware picker: removed operations remain visible as disabled drift, newly introduced operations stay unchecked, and an explicit empty policy remains empty.

Durable card revisions and catalog versions live in Connection Hub bundle storage. Redis carries a rebuildable serving projection; losing it does not erase granted authority. Generic named-service calls resolve the current card and catalog, then run explicit admission for the decoded namespace and operation on every invocation.

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

Delegated authority and admission architecture

Allow Automation To Use Your Applications

One record shape: resource_grants

Related documentation