Softlander Book a call
Agent identity, authorisation, and delegation

Identity propagation across tools

Carry the correct actor context through tool integrations

A gateway converts user requests into downstream service-account calls. The decision is how to carry the correct actor context through tool integrations. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to integration architects and IAM owners. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.

Book a 30 minute readiness callBrowse this capability group

The identity and delegated authority relationship

  1. Starting evidenceIdentity claims

    Establish the basis for incoming claims.

  2. Decision boundaryGateway mapping

    Expose attributes removed or substituted.

  3. Decision artefactIdentity propagation map

    Retain the scoped finding and its unresolved dependencies.

Conceptual model. Technical findings do not settle a disputed mandate.

Decision

Frame the decision around incoming claims

Questions and the evidence they need

Criterion / evidenceIncoming claims
Inspect identity claims for the relevant constraint or observation.
Criterion / evidenceGateway mapping
Inspect gateway mappings for the relevant constraint or observation.
Criterion / evidenceResource event
Inspect tool requests for the relevant constraint or observation.
Read each criterion against the available evidence before deciding that additional work is needed.

The decision is how to carry the correct actor context through tool integrations. This is relevant to integration architects and IAM owners when a gateway converts user requests into downstream service-account calls. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.

The specific failure hypothesis is that the original user or tenant disappears at a translation layer and broad service authority takes over. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.

Mechanism

Tool boundaries must retain the original authority context

Relationships within identity and delegated authority

Source or conditionIncoming claims
Identify user, delegator, tenant, and action scope.
Crossing or choiceGateway mapping
Expose attributes removed or substituted.
Consequence or decisionResource event
Match the final operation to the original mandate.
Follow the check to the accepting resource. Each relationship needs evidence in the actual scope.

What this specialty examines

Identity propagation should preserve both actor and delegation context. A downstream system may need to know the workload, originating user, tenant and mandate, but each field has its own trust source. Blindly forwarding unverified claims is not reliable propagation.

The review should trace subject, delegator, tenant and action context across each protocol and tool boundary. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.

The tradeoff to make explicit

For this decision, context preservation supports accountability while each downstream system may represent identity differently. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.

Preparation

Connect the working inputs to the boundary being examined

Evidence packet for incoming claims

Illustrative working format

BasisIdentity claims
Use nonsecret metadata to trace issuance, acceptance, and withdrawal responsibility.
ContextGateway mappings
Match this description to the deployed or proposed boundary being examined.
ObservationTool requests
Name the custodian and the conditions requiring a refreshed version.
DependencyResource audit logs
Retain the observed conditions and distinguish gaps from contrary evidence.
Illustrative preparation record. Availability, revision, and handling need confirmation.

Start with identity claims, gateway mappings, tool requests and resource audit logs. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.

The scope also needs the identity control owner, agreed expectations for a representative subject-action-resource case, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which the original user or tenant disappears at a translation layer and broad service authority takes over from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.

How the work proceeds

Carry incoming claims through to an accountable finding

From the scoped material to a decision record

  1. Establish conditionsIdentity claims

    Locate the source of the claimed authority.

  2. Examine the relationshipGateway mapping

    Apply the scoped check to resource event.

  3. Retain the findingIdentity propagation map

    Record the evidence, open dependencies, and the owner’s next decision.

Proposed sequence; resolve interpretation or access gaps before relying on the next step.

Map principals, resources and authority

Reconcile identity claims, gateway mappings, tool requests and resource audit logs with the workflow described by integration architects and IAM owners. Identify the initiating actor, executing workload, target resource and component that grants access. Prepare paired cases that differ in one material authority condition, such as assignment, tenant, expiry or approval. The preparation output is an action map showing which permission is expected at each boundary and which records can verify it.

Exercise and review the authority path

Map transformations at gateways and adapters. Check whether fields are dropped, renamed, replaced or cached, and whether resource enforcement uses the intended values. Preserve correlation identifiers so the business action can be reconstructed across systems with different identity models.

Select the identity control change

Consolidate the checked paths into an identity propagation map with loss and substitution findings. Distinguish an identity-verification problem from an excessive permission, lost delegation context or delayed withdrawal. Assign the proposed change to the component that controls the affected action. Before recommending wider use, identify the allowed case and denied counterpart that would demonstrate the revised boundary without breaking legitimate work.

Indicative artefact

Make the identity propagation map usable by its owner

Identity propagation map

Illustrative working format

Annotated fieldIdentity propagation map
Identify the assessed workflow, revision, and decision boundary.
Annotated fieldLoss
Link supporting and contrary observations to inspectable evidence.
Annotated fieldSubstitution findings
Link observations and counterevidence to the case, configuration, and conclusion limit.
Illustrative artefact structure, not a completed engagement or an observed result.

A useful decision artefact is an identity propagation map with loss and substitution findings. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.

Illustrative scenario

Examine resource event through a constructed exception

A constructed case and its decision paths

Illustrative scenario

  1. SituationIncoming claims

    A gateway replaces the user context with a shared integration identity.

  2. Question to examineGateway mapping

    Compare claims before the gateway with resource-side audit evidence.

  3. Conditional next actionResource event

    Restore missing user and tenant context before relying on attribution.

Fictional example. No executed test, customer engagement, or measured outcome is implied.

Consider a fictional situation: a CRM connector records every action under a shared bot account, hiding who authorised a particular change. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.

For shared CRM attribution, determine whether a trusted gateway can enforce per-request authority and retain the originating context. If not, state the resulting control and investigation limits. A bot label alone cannot answer who authorised a particular action.

Scope and next action

Keep the conclusion within named authority paths

Confirm fit before the next commitment

Included boundaryIncoming claims
This review is limited to named authority paths.
PrerequisiteIdentity claims
The relevant owner must confirm access and the intended operating conditions.
Claim limitIdentity propagation map
Technical findings do not settle a disputed mandate.
Bring the triggering change and existing evidence; resolve the dependency that could alter the decision.

Identity design and technical testing do not establish a legal mandate or resolve a disputed business authorisation. Qualified IAM review is needed for material control conclusions. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which a gateway converts user requests into downstream service-account calls; confirm which missing observation would change the owner’s next action.

Ways to engage

Related engagement scopes

Agent Release Readiness Review

The Agent Release Readiness Review is a fixed-scope, three-week independent test of one AI agent workflow that shows a release board what the agent does, what it is allowed to do and what happens when it is wrong, and ends in a signed recommendation.

3 weeksRead about this offer

AI Agent Authorisation Review

Make delegated authority inspectable. Trace who an agent acts for, what it can access and how that access can be withdrawn.

Read about this offer

AI Agent Runtime Security Review

Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.

Read about this offer

Continue exploring

Related insights and resources

Whitepaper15 MIN READ

Designing agent authority boundaries

Turn agent permissions into an enforceable action contract. Separate a model's suggestion from a resource owner's authorisation, test the boundary, and make delegation and revocation reviewable.

Agent security6 MIN READ

The permission boundary behind every agent action

An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.

Whitepaper5 MIN READ

Before your agent can act, define its authority

A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.

A little more clarity

Questions to consider.

Start with the questions that shape a better decision.

What if a tool only supports a shared service account?

Document the constraint and examine whether a trusted gateway can enforce per-request scope and retain origin context. If it cannot, attribution and least-privilege limitations remain material and should constrain the proposed use.

Which records preserve identity through tool gateways?

Start with identity claims, gateway mappings, tool requests and resource audit logs. Record their revision, owner and relationship to the intended workflow. Missing context should be identified before interpreting outcomes; a sanitised fixture is useful only when its relevant differences from the operating case are understood.

How should dropped or substituted actor context be tested?

Trace subject, delegator, tenant and action context across each protocol and tool boundary. Observe the authenticated principal, mandate and resource decision separately. Include a permitted action and a denied counterpart so the review can establish whether authority is narrow enough without making legitimate work impossible.

What should an identity propagation map reveal?

The proposed output is an identity propagation map with loss and substitution findings. Include the selected conditions, supporting observations, unresolved differences and next decision. A reviewer should be able to follow each important conclusion back to its evidence and understand the limits without depending on an undocumented explanation from the author.

When is shared-account attribution inadequate?

Shared attribution is inadequate when the business needs to distinguish requesters, mandates, tenants or agent revisions and the available records cannot do so. State those limits rather than inferring an individual actor from a bot account.

What if existing evidence already answers the question?

Review its scope, provenance and configuration before proposing new work. Existing work from integration architects and IAM owners may already be sufficient. In that case, capture the decision, unresolved limitations and the change that would require another review. Additional assessment should address a real gap.

What would make the findings inconclusive?

Missing identity claims, gateway mappings, tool requests and resource audit logs can prevent a reliable interpretation, depending on the case. Record the specific missing observation and its implication. The owner can supply evidence, narrow the claim or defer the dependent decision; an incomplete case should not silently be counted as a pass.

Start with the decision you need to make.

Tell us about the agent workflow you want reviewed, and where you need greater clarity. Scope and availability are confirmed together.

Book a 30 minute readiness call Get the agent release checklist

Connected disciplines

Cross-tenant identity isolation

Verify that agent identity cannot cross tenant boundaries. The review connects tenant-principal mappings, token claims, resource partitions and synthetic tenant fixtures to a bounded review of identity and authority, giving the identity control owner a clearer basis for the next action.

Agent attribution and non-repudiation

Make consequential agent actions attributable to an accountable chain. The review connects event schemas, timestamps, identity evidence, delegation records and integrity controls to a bounded review of identity and authority, giving the identity control owner a clearer basis for the next action.

Authorisation policy testing

Verify authorisation policy decisions against intended rules. The review connects policy versions, subject-resource fixtures, action catalogues and expected decision tables to a bounded review of identity and authority, giving the identity control owner a clearer basis for the next action.