Reading a delegation chain: who authorised what

Ownership before delegated authority

The ownership question is who is accountable for an agent. The delegation question is whose authority the agent exercises for a particular resource. The current capability definitions separate these questions because a named owner can exist without an on-behalf-of access flow. A buyer should avoid using the same directory screenshot as proof of both. [silverfort-c5-1]

Silverfort documents mapping agents to accountable human owners, while the registry explicitly distinguishes that attribution from an on-behalf-of token flow. The ownership information remains useful for accountability. The missing delegated flow is a separate evidence boundary, not a reason to erase the documented strength in owner mapping. [silverfort-c1-1] [silverfort-c5-1]

The links that need inspection

The design tenets call for a cryptographic link between an agent and the entity that started its task, with delegated scopes attenuating along the way. That is a stronger requirement than a log entry naming an initiating user. The evaluation needs to show how the receiving component recognises the authority and prevents a later step from broadening it. [f1-detail]

The most useful reading order starts at the task originator and follows the request towards the tool. Each transition should preserve enough context to explain the authority being used. The buyer should record what is asserted, what is enforced and what is merely written to an audit trail, since these are different functions even when one product exposes them together. [f1-detail]

• initiator: the user or entity starting the task
• agent: the principal performing the requested work
• resource: the destination for the delegated access
• limits: the permitted scope and applicable lifetime
• decision: the control that accepts or refuses the request
• record: the evidence connecting the action to its authority

The documented access patterns

Aembit describes blended human-agent context and per-request credential exchange. The product’s documentation supports inspection of a flow in which the human on whose behalf an agent acts remains part of the access context. The registry does not establish broad shadow-agent discovery or a human approval workflow from that gateway documentation. Those are separate capabilities rather than implied parts of delegation. [aembit-c5-1] [aembit-c4-1] [aembit-c7-1]

Keycard documents user-on-behalf access and previously authorised background access. That distinction is useful because a background task should not be evaluated as though a person necessarily approves every invocation. Keycard also describes step-up approval for sensitive actions. The test should identify which access pattern is in use and which conditions actually trigger that step. [keycard-c5-1] [keycard-c7-1]

The connection modes and preserved context

The Idira documentation distinguishes managed authorization from passthrough behaviour. In managed mode, upstream tokens are handled and agent and user identity are captured for delegated access. The registry also states that connection mode is fixed at registration. A buyer therefore needs to inspect the selected connection mode rather than generalising one mode’s properties across every deployment. [palo-alto-idira-c5-1] [palo-alto-idira-c8-1]

Descope describes user-linked access on behalf of a user and background access, together with an audit trail tying agent actions to the originating user. Those documented capabilities are relevant to chain inspection. The public record still leaves implementation and plan entitlement for human approval to be confirmed, so attribution should not be presented as proof that a person approved each action. [descope-c5-1] [descope-c6-1] [descope-c7-1]

The approval as a separate event

NewCore’s sourced description distinguishes policy approval from human approval in its audit trail and describes session- and task-specific identities. The product’s delegated access guide concerns access to tool servers. NewCore is an agent governance layer alongside the existing identity provider, and its pricing is not public. The distinction between approval types is useful without treating it as evidence that every deployment has identical approval rules. [n1] [newcore-ema]

The approval record should explain whether a policy allowed the action automatically or a human intervened before execution. The buyer can then compare that event with the original delegated scope. A person approving a sensitive step does not by itself explain all downstream permissions, just as an authorised delegated session does not prove that every later action received human review. [n1] [f1-detail]

A focused demonstration

The demonstration should follow one permitted request and one request outside its delegated authority. The evaluator can ask for the originating identity, acting agent, destination and resulting decision in each case. The aim is not to demand a particular token layout without evidence, but to verify that the documented restrictions survive the actual access path. [f1-detail]

The final record should state which links were observed and which remain documentary claims. A lineage map can help locate agents, tools and resources, but it is not interchangeable with a delegated token flow. Token Security illustrates that boundary: identity lineage is mapped, while an explicit delegated flow was not verified in the registry. The distinction keeps the assessment useful without overstating either capability. [token-security-c1-1] [token-security-c5-1]

What readers ask