Authenticate an agent acting on a user's behalf through a trusted application session and an explicit delegation path to each connected service. Keep the user, agent workload, and executor identities distinct. Issue narrowly scoped credentials outside model context, check resource authorization on every operation, and revalidate approval and permissions before a separate executor performs outward writes.
Authentication answers only part of the question
Authentication establishes who or what is presenting a request. Authorization decides whether that identity may perform the requested operation on the target resource. Delegation explains why a workload is permitted to act in a user's context. An agent workflow needs all of these relationships to be explicit.
Consider a hypothetical assistant drafting a change to an internal service request. The employee signs into the product, the agent retrieves permitted records, and an authorised reviewer decides whether the proposed change should proceed. The executor then applies that approved change using its own controlled integration identity.
Treating every step as simply “the user did it” loses essential accountability. The user requested work, the model prepared a proposal, the reviewer authorised specific content, and the executor attempted a write. Each actor belongs in the record with the authority relevant to its actual role.
Start delegation in trusted application code
Derive the user's identity and organisation context from the authenticated application session. Do not accept a model-generated user identifier, email address, or role as proof of identity. Those values may help locate a record, but trusted server-side context must determine whose authority applies.
Where a connected service supports delegated authorization, use the supported flow and retain the scope of that delegation. Where it requires a workload identity, document the application checks that preserve the user's permitted access. A service account's ability to read a record does not establish the requesting employee's entitlement to it.
Keep credentials in the integration infrastructure. Tool descriptions should state permitted operations and argument shapes without exposing access tokens, refresh credentials, or client secrets. The agent needs the outcome of an authorized lookup, not the material that would let it impersonate the connector elsewhere.
Bind credentials to the intended destination
A token for a document service should not become a general credential for unrelated tools. Validate the issuer, audience, validity, and required permissions according to the receiving service's protocol. Reject a token whose intended resource does not match the endpoint handling the request.
The OAuth security guidance in RFC 9700 recommends audience restriction to reduce reuse of captured tokens at other resource servers. For agent integrations, the practical design question is which service each credential is intended to reach and where that restriction is checked.
Token handling belongs in a reviewed connector implementation. Avoid allowing the model to construct arbitrary authenticated URLs or choose credential destinations. Define the service route in code and let the agent supply only validated business arguments that the tool contract explicitly accepts.
Preserve user context across background work
An agent may finish preparing a proposal after the user's interactive session ends. Decide whether that work is permitted to continue, what authority it retains, and when access must be renewed. A background job should not silently convert a temporary delegated task into a permanent entitlement.
Store a reference to the originating request and its identity context without copying secrets into job payloads. At each protected operation, resolve the current authority the workflow requires. If the user loses access, the organisation changes, or delegation is withdrawn, pause the affected work and record why it cannot proceed.
Do not equate token validity with business permission. A credential may still be technically valid while a source record has moved to a restricted group or the requester's role has changed. Resource-level checks remain necessary even when the authentication handshake succeeds.
Separate proposal authority from execution authority
CodeDTX's Propose–Decide–Execute pattern draws a deliberate boundary: the agent writes an evidence-backed proposal, a named human decides, and a separate executor performs approved outward writes. The agent does not hold the executor's outward write credentials.
Bind a decision to the proposal content, target, and relevant context. If the agent edits the destination record or proposed field after approval, the previous decision should not authorize the revised action. The executor should verify that the proposal presented for execution is the version the reviewer actually approved.
Recheck the destination's current state as well. A legitimate approval does not require the executor to ignore a newly restricted resource or a business condition that changed while the request waited. Preserve a visible expired or blocked state and route the changed situation through review again.
Design revocation and failures as normal workflows
Expired delegation, unavailable identity services, and revoked permissions should have defined behaviour. The product can ask the user to reconnect an account or explain that a reviewer no longer has authority. It should avoid exposing token internals or suggesting that the user paste credentials into a conversation.
Distinguish authentication failure from insufficient permission and from an unavailable dependency in protected diagnostics. Those conditions need different remedies. Retrying an unauthorized operation with broader credentials conceals the real problem and changes the security boundary without a decision.
For an executor timeout, first establish whether the destination accepted the write. Authentication renewal must not cause an already completed operation to be repeated accidentally. Preserve the action reference across retries and reconcile with the target system before declaring success or attempting another write.
Test the identity transitions, not just login
A working sign-in screen does not demonstrate a correct delegated workflow. Exercise requests from users with different entitlements, a changed organisation context, revoked access, a mismatched token audience, and an approval recorded by someone who lacks the required decision role.
Inspect identity across retrieval, proposal creation, review, and execution. The record should make it possible to explain which principal read evidence and which principal changed the destination. Credentials must remain absent from the model context, user-facing errors, and broadly accessible trace exports.
These tests fit alongside secure data access and enterprise AI integration. The useful release evidence is a demonstrated boundary that holds when identity changes mid-workflow, not a successful demonstration performed entirely under an administrator account.
Frequently asked questions
Should an agent have its own identity?
The executing workload should have an identifiable service identity, distinct from the employee who requested the task. When it acts in a user's context, preserve that relationship explicitly. Separate identities make it possible to constrain infrastructure access, revoke a workload, and reconstruct who requested, proposed, approved, and executed a particular operation.
Should access tokens appear in the agent's prompt?
No. Keep credentials in the integration layer and expose narrowly defined tools that return permitted business results. Including a token in model context unnecessarily gives sensitive authentication material to additional processing and logging paths. The model should neither choose where credentials are sent nor receive secrets as part of a tool response.
What if the user's session expires while a proposal waits?
The proposal can remain as a recorded artifact, but its existence does not preserve authority indefinitely. Apply the workflow's policy for renewed identity, current resource permissions, and valid decision roles when work resumes. If the required authority is no longer available, hold the action and make the reason visible to the appropriate operator.
Does a human approval replace authorization checks?
No. Approval records a decision about a particular proposed action; authorization establishes whether the actors and executor may perform it against the current resource. The executor should check both. A reviewer cannot grant permissions they do not hold, and an earlier approval should not override a restriction introduced before execution.
