On-behalf-of delegation

What does delegation change?

An agent acting for a person needs more than access to that person's applications. It also needs a distinct identity and a bounded grant of authority.

Handing over a user token can conceal which actor made a request. Delegation should preserve the relationship between the person, the agent and the requested work.

NewCore documents identifying both parties on every tool call and keeping agents within the permissions of the person they represent. Aembit calls its combined agent and human context a Blended Identity.

Treat these as implementation claims to verify, not proof that every downstream application records both identities. Ask to see the resulting request and audit record.

How should the access flow work?

Keep employee sign-in with the existing identity provider. Authenticate the agent separately, then request narrowly scoped access for the intended application and task.

Use a broker or gateway to obtain downstream credentials rather than exposing standing tool credentials to the agent. NewCore documents short-lived, task-scoped access with tool credentials withheld from agents.

Aembit documents secretless exchange through its MCP Identity Gateway. Descope documents short-lived scoped tokens and support for Cross App Access, SPIFFE, mTLS and DPoP.

Access issuance and action authorization answer different questions. Getting a token for an application does not establish whether a particular deletion or export should proceed.

Require the enforcement point to evaluate each relevant call. Record the person, agent, destination, requested action, decision and approval when applicable.

A hypothetical worked example

Imagine a support employee asking an agent to prepare a customer refund. This example describes a proposed control design, not a documented customer deployment.

The employee signs in normally, and the agent authenticates with its own identity. A task grant permits reading the relevant order and drafting a refund.

The gateway allows those reads but sends the refund submission to a named approver. The agent cannot approve the request through its own session.

If the employee lacks refund authority, the task grant must not create it. If policy denies bulk exports, a refund request must not bypass that restriction.

After approval, the permitted submission runs and the audit record links both identities with the decision. Test agent revocation separately from employee account revocation.

Which products address which layer?

Okta registers agents in Universal Directory, assigns human owners and replaces hardcoded credentials with short-lived tokens. Its Agent SSO uses Cross App Access and is included in core Okta SSO.

The reviewed Okta material lists Agent Gateway and human-in-the-loop capabilities as coming after general availability. Do not procure an announced capability as though it were already delivered.

Aembit suits evaluations focused on secretless exchange and MCP request enforcement. Its gateway runs on a customer-hosted VM, which belongs in deployment and operating-cost discussions.

NewCore documents allow, ask and deny decisions, per-agent revocation, and a unified trail of calls, sessions and approvals. Named approvers confirm risky actions in its app using device biometrics.

Descope documents per-tool authorization and Deny policies. Its governance suite includes approval, documented purpose and an accountable owner, but requires the Enterprise plan.

How should a team implement it?

Step 1: choose one agent and one application. List the user's permissions, the agent's tools, existing credentials and actions that require approval.

Step 2: assign a distinct agent identity and an accountable owner. Map the agent to the person represented without confusing that person with the operational owner.

Step 3: replace standing access with short-lived grants. Check the destination, scope and task boundary before testing successful and rejected calls.

Step 4: enforce action policy and independent approval. Include tests where the user has permission but the agent should still be denied.

Step 5: inspect evidence and revoke the agent. Expand only after the pilot demonstrates that approval, denial and revocation work across the actual application path.

What should procurement require?

Request a demonstration using your identity provider, agent runtime and target application. A standards list alone does not demonstrate interoperability across that complete path.

Ask vendors to distinguish authentication, credential exchange, per-call enforcement and human approval. Require separate evidence for each capability that your design depends upon.

Define acceptance tests for approval routing, agent-specific revocation, task expiry and audit export. Include an attempted direct tool call that bypasses the proposed gateway.

Price the needed controls rather than the entry tier. Aembit lists a free Starter tier for three agents; Descope's free hub excludes its Enterprise governance suite.

Include downstream application logs in the evaluation. Confirm that exported records let an investigator distinguish direct employee activity from delegated agent activity.

Which pitfalls should the pilot expose?

Do not treat a human owner as the person whose authority the agent uses. Ownership establishes accountability; delegation establishes whose permissions constrain a particular task.

Do not assume token expiry cancels credentials already issued elsewhere. Ask the vendor to demonstrate revocation behavior for every downstream integration in scope.

Avoid approval designs controlled by the requesting agent. Require an independent human interaction and evidence connecting the approval to the exact proposed action.

Finally, distinguish missing evidence from missing capability. When reviewed material does not document a feature, request proof rather than asserting the vendor cannot provide it.

Questions buyers ask