THE AGENT IS NOT THE AUTHORITY

Series and research perspective

A Pre-Disclosure Evidence Infrastructure Perspective on Agent Identity, Delegated Authority, Autonomous Execution and Institutional Responsibility

Evidence Infrastructure Analysis

Evidence Infrastructure Analysis examines the institutional conditions under which information becomes attributable, interpretable and capable of supporting consequential decisions.

Previous editions have examined how evidence loses validity after deployment, how institutional relationships differ from technical connections, how structured evidence participates in decision processes, and how multiple evidence histories remain attributable across time.

These questions become more consequential when artificial intelligence systems move beyond generating information and begin executing actions.

An AI agent may retrieve corporate information.

It may interact with enterprise applications.

It may initiate procurement activities.

It may generate software changes.

It may communicate with external organisations.

It may delegate tasks to other agents.

And, under certain configurations, it may execute transactions without requiring a human decision at every intermediate step.

These capabilities introduce a question that is not resolved by identifying the agent or recording its actions.

Who authorised the action, under which conditions, and what evidence demonstrates that the authority remained valid when the action occurred?

This edition examines the relationship between autonomous execution and institutional authority.

It distinguishes technical identity, delegated permissions, runtime authorisation, recorded execution and subsequent accountability.

The research begins with recent developments from the US National Institute of Standards and Technology, the Financial Stability Board and the UK Information Commissioner's Office.

These institutions address different aspects of agentic AI governance.

They have not established a single coordinated international standard for autonomous agents.

Nevertheless, their work reveals a common institutional concern.

As AI systems become capable of acting across tools, organisations and operational environments, the relationship between what a system can execute and what it is authorised to execute must remain distinguishable.

The agent may perform the action.

The institution must still be able to establish the authority behind it.

Executive Summary and Opening Reflection

Executive Summary

Agentic artificial intelligence introduces a structural change in enterprise automation.

Traditional software systems generally operate through predefined processes, permissions and execution conditions.

Agentic systems can select among possible actions, interpret changing information, interact with tools and pursue delegated objectives with varying degrees of autonomy.

This flexibility creates new challenges for identity, authorisation, operational control and institutional accountability.

On 27 October 2026, NIST published Design Tenets for Agent Identity Management Systems, proposing ten initial design principles for managing the identity, authentication and authorisation of AI agents. [1]

The principles address distinct agent identification, delegated authority, least privilege, revocable authorisation, human oversight, mandates, separation of policy from reasoning, deterministic access decisions, continuous monitoring and independently preserved evidence.

The tenth principle, Immutable Evidence, proposes that agent identity, delegated intent and resulting actions should be captured in a tamper-evident, append-only evidence history maintained independently of the agent.

These are initial design principles published in a NIST technical blog.

They are not an internationally mandatory agent-authorisation standard.

Their importance lies in the implementation questions they identify.

On 15 October, the Financial Stability Board published its final report containing 12 Sound Practices for Responsible Adoption of Artificial Intelligence in financial institutions. [3]

The practices address board oversight, defined responsibilities, AI risk management, effective documentation, human oversight, cybersecurity and third-party dependencies.

They are non-binding sound practices tailored to financial institutions, not universal corporate legal requirements.

On 8 October, the UK Information Commissioner's Office opened a call for evidence on agentic AI, examining data security, transparency, accountability, automated decision-making, purpose limitation and the lawfulness of personal-data processing. [4]

The consultation closes on 20 November 2026.

It has not yet resulted in final new guidance.

Together, these developments support a central research question:

How can an enterprise demonstrate that an autonomous AI action was performed under valid institutional authority, rather than merely through technically available permissions?

This analysis distinguishes four concepts.

Agent Identity

The technical ability to identify which agent or workload performed an action.

Delegated Authority

The institutionally established permission to perform specified activities under defined conditions.

Autonomous Execution

The actual attempt or performance of an action through a tool, service or operational environment.

Institutional Accountability

The responsibility for authorising, governing, reviewing and responding to the action and its consequences.

These concepts are related.

They are not interchangeable.

An agent may authenticate successfully without having permission for a particular task.

It may possess valid credentials while attempting an action outside the intended mandate.

It may remain technically capable of execution after the relevant institutional authority has changed or been revoked.

And a tool may report successful execution without establishing that the resulting action was legally effective, appropriate or aligned with the organisation's objectives.

This publication examines these distinctions through a Pre-Disclosure Evidence Infrastructure perspective.

Its core proposition is:

The authority to act must remain independently attributable and verifiable, rather than being inferred from an agent's identity, credentials or execution success.

This proposition does not mean that every action requires fresh human approval.

It means that the authority applicable to each consequential action must remain sufficiently defined, enforceable and reviewable within the relevant institutional arrangements.

Opening Reflection

The Transaction Succeeded. Was It Authorised?

Consider a hypothetical enterprise using an AI agent to support procurement.

A purchasing manager gives the agent a task:

Identify an eligible supplier, compare available quotations and place an order within an approved budget.

The agent accesses the procurement system.

It retrieves vendor information.

It compares prices.

It selects a supplier.

It submits an order through an authorised API connection.

The system returns a successful transaction response.

The activity log identifies the agent.

The API credential was valid.

The order appears in the purchasing system.

Technically, the operation succeeded.

But several questions remain.

Was the selected supplier eligible under the company's procurement policy?

Was the amount within the delegated spending limit?

Was the authorisation valid at the moment of execution?

Had the manager's authority changed?

Did an external document contain instructions that redirected the agent beyond its original task?

Did the agent delegate part of the work to another service?

And did the receiving system independently enforce the relevant restrictions?

A successful API response does not answer all these questions.

Neither does the fact that the agent was authenticated.

The institutional problem begins when technical execution is interpreted as proof of authority.

The system can establish that an action occurred.

A separate evidentiary relationship is needed to establish why the action was permitted.

Identity, delegation and autonomous execution

01 | Identity Is Not Authority

Authentication Establishes Identity, Not Unlimited Permission

A fundamental principle of identity and access management is the distinction between authentication and authorisation.

Authentication concerns the identity of the entity requesting access.

Authorisation concerns whether that entity may perform a particular action against a particular resource under applicable conditions.

NIST Special Publication 800-207, Zero Trust Architecture, recognises these as distinct functions and rejects implicit trust based solely on network location or ownership of a resource. [5]

The distinction becomes especially important for agentic systems.

An AI agent may hold credentials allowing it to interact with multiple applications.

These credentials may be valid and correctly associated with the agent.

But the agent's possession of a credential does not necessarily establish that every conceivable use of the connected application has been authorised by the enterprise.

Distinct Agent Identification

NIST's first proposed design tenet calls for AI agents to have identities distinguishable from human users and ordinary service accounts.

Such identities should, where appropriate, be associated with a specific workload, environment and approved configuration. [1]

This provides an important starting point.

A shared human account may make it difficult to determine whether a human or an autonomous system performed an action.

A distinct agent identity can improve technical attribution.

However, an agent identifier does not independently establish the source or scope of the agent's delegated authority.

An organisation may know exactly which agent placed an order while remaining unable to demonstrate that the order was authorised.

Identity Has Multiple Layers

An enterprise agent may be associated with:

A logical agent identity.

A deployed workload or runtime instance.

An operational configuration and model version.

One or more technical credentials.

A human or organisational task originator.

An applicable institutional mandate.

A tool or external service receiving the request.

These relationships may change over time.

Credentials may rotate.

An agent may be redeployed.

Its configuration may be updated.

Its task may be modified.

A previously authorised individual may leave the organisation.

Therefore, determining the identity of the agent is not necessarily the same as identifying the institutional authority governing a historical action.

Agent identity is necessary for attribution.

It is not sufficient evidence of authorisation.

02 | The Delegation Problem

Who Granted the Authority, and What Was Actually Granted?

Autonomous agents commonly act on behalf of a person, organisation or another software component.

This creates a delegation relationship.

But delegation should not be interpreted as an unrestricted transfer of authority.

NIST's second proposed design tenet addresses agent linking, delegation and attenuation.

It proposes that agents remain linked to their task originators and that delegated permissions become no broader as authority passes to downstream agents or services. [1]

The principle is significant because autonomous execution may involve several connected agents.

Delegation Has More Than One Dimension

A meaningful mandate may need to establish:

The principal

Which person or institution originated or authorised the task?

The delegate

Which agent is permitted to act?

The purpose

What outcome or activity is the agent authorised to pursue?

The scope

Which tools, resources, counterparties or actions are permitted?

The constraints

What limits apply to transaction values, destinations, data use or operational behaviour?

The period

When does the authority begin, expire or become subject to reassessment?

The escalation condition

Which actions require additional approval?

The revocation condition

How can the institution withdraw or modify the permission?

The precise implementation depends on the system and risk involved.

Not every agent requires the same form of mandate.

But the conceptual distinction remains important.

An agent's ability to invoke a tool does not establish that invoking the tool for a particular purpose falls within the original delegation.

Technical Delegation and Institutional Authority

IETF RFC 8693, OAuth 2.0 Token Exchange, provides an established technical reference for distinguishing delegation from impersonation.

It defines token-exchange mechanisms and describes how subject and actor identities can be represented when one party acts on behalf of another. [6]

The specification also allows delegation history to be represented through actor claims.

This provides a technical means to express particular delegation relationships.

It does not independently determine whether the original principal possessed the relevant legal or organisational authority.

A technically valid delegated token may accurately identify the parties involved while leaving substantive questions unresolved.

For example, an employee may successfully initiate a delegated workflow despite lacking corporate authority to approve the underlying transaction.

The token may be authentic.

The institutional authorisation may still be insufficient.

No Automatic Expansion of Authority

Consider an agent authorised to evaluate suppliers and prepare a proposed order.

It delegates supplier research to another agent.

The second agent should not acquire authority to approve payments merely because the first agent has access to a procurement environment.

The authority attached to the original mandate does not automatically expand through delegation.

A new action outside that mandate requires an appropriate independent basis.

This principle is particularly important where agents interact across organisational boundaries.

The task originator, agent operator, tool provider and receiving institution may be different entities.

Each may have different responsibilities and trust requirements.

A chain of technical delegation does not automatically create a chain of valid institutional authority.

03 | When an Agent Acts

The Difference Between a Proposed Action and an Authorised Action

Agentic systems can transform a broad objective into specific tool operations.

A purchasing task may become a supplier search, quotation comparison, vendor selection and order submission.

A software maintenance task may become a code change, test execution and production deployment.

The action selected by an agent may depend on probabilistic reasoning, context interpretation and information retrieved from external sources.

The authority to execute that action should not depend solely on the agent's own assertion that the action is appropriate.

Policy Must Be Separated From Reasoning

NIST's seventh and eighth proposed design tenets address this distinction directly.

They recommend separating the agent's reasoning process from the systems that determine which actions it is allowed to perform.

They also recommend using deterministic access decisions as the primary mechanism for authorisation. [1]

The underlying concern is that an agent may encounter untrusted information.

A retrieved webpage may contain instructions.

A supplier document may include misleading content.

An external system may return data that the agent incorrectly interprets as a command.

Such information should not automatically change the agent's authority.

A prompt cannot legitimately enlarge the permissions granted by an institution merely because it appears in the agent's operating context.

The Runtime Authorisation Question

An agent may have been authorised when its task began.

But circumstances may change before execution.

A purchasing threshold may be reduced.

A credential may be revoked.

A vendor may be suspended.

A transaction may exceed a permitted amount.

The task may drift from its original purpose.

For consequential operations, the system may therefore need to evaluate whether the relevant authority remains valid at the point of action.

NIST's fourth design tenet proposes short-lived, dynamic and revocable authorisation, including runtime verification for individual resource access and tool invocations. [1]

This is an architectural recommendation.

It is not a statutory requirement applicable to every AI agent.

Its relevance lies in distinguishing historical permission from present permission.

Execution and Its Consequences

Suppose an agent successfully submits a purchase order.

The technical record may establish that:

A specified request was sent.

The receiving service authenticated the request.

The service returned a successful response.

But additional evidence may be necessary to establish:

Whether the order complied with corporate policy.

Whether the relevant counterparty was authorised.

Whether the transaction created an enforceable obligation.

Whether goods were actually delivered.

Whether payment was validly approved.

Whether the transaction produced the intended business result.

These questions involve different institutional authorities and potentially different legal frameworks.

Successful execution proves neither unlimited authority nor successful institutional outcomes.

Multi-agent responsibility and independent evidence

04 | Multi-Agent Systems and the Expansion of Responsibility

Delegation Becomes More Difficult Across Agents and Organisations

An autonomous task may involve more than one agent.

A primary agent may coordinate research.

A second may prepare documents.

A third may execute transactions.

An external provider may operate one of the connected services.

This architecture may improve efficiency.

It also creates additional questions concerning authority.

Which agent originated an action?

Which agent actually performed it?

Which institutional principal authorised the activity?

Did the downstream agent remain within the original scope?

Was the receiving organisation entitled to rely on the delegated authority presented?

Identity Relationships Are Not Equivalent to Authority Relationships

A multi-agent system may correctly identify every participating software component.

That does not establish that every delegation was valid.

Likewise, a nested delegation record may preserve the sequence of actors without proving that each actor was entitled to extend permission.

The question is not only whether an authority chain can be reconstructed.

It is whether the authority represented at each step remained within the applicable institutional restrictions.

This is particularly important when different organisations operate different parts of the workflow.

An external application may receive a technically valid request without having access to the full internal business purpose behind it.

Its access-control decision may be based on available credentials and specified claims.

The enterprise may separately need evidence that the underlying activity was properly authorised.

The Confused Deputy Problem

NIST identifies the confused deputy problem as one risk relevant to agentic delegation.

An agent with legitimate access may be manipulated into using that access for an unintended purpose.

The agent's credentials remain technically valid.

The requested action may nevertheless conflict with the task originator's actual intent.

NIST therefore presents identity linking, least privilege, separation of policy from reasoning and deterministic access decisions as complementary protections. [1]

No single control eliminates every possible failure.

A correct agent identity does not independently prevent misuse.

A signed mandate does not necessarily prevent misinterpretation.

A successful policy check does not guarantee the resulting business action was beneficial.

And a retained log does not reverse an irreversible unauthorised action.

Multi-Agent Evidence Must Preserve Distinctions

Relevant information may include:

The initiating principal.

The primary agent.

Each downstream actor.

The task delegated to each actor.

The scope of the authority passed onward.

The policy applicable to each action.

The executing service.

The resulting action and response.

Changes to permissions during execution.

But the objective should not be unlimited monitoring.

The necessary information depends on risk, legal requirements and the intended review purpose.

A system involving more agents does not automatically have more legitimate authority.

Authority must remain constrained as tasks are distributed.

05 | Evidence Must Not Depend Entirely on the Agent

A System Should Not Be the Sole Custodian of Its Own Actions

An autonomous agent may create operational logs.

It may summarise its activities.

It may generate explanations.

It may produce reports describing what it attempted or completed.

These records can be useful.

But they create an important control problem when the same agent can alter or delete the only evidence of its actions.

NIST's tenth design tenet addresses this through the concept of Immutable Evidence.

It proposes maintaining an append-only, tamper-evident chain of custody independently of the agent, linking its identity, delegated intent and resulting actions. [1]

This is one of the most directly relevant developments for Pre-Disclosure Evidence Infrastructure.

The Agent's Account Is Not Independent Verification

Suppose an agent reports:

The purchase was authorised and completed successfully.

This statement may be accurate.

But the statement alone is not independent evidence of the underlying authorisation.

A review may require the original mandate, applicable policy, relevant permission state, actual tool request and receiving system's response.

If the only available evidence is the agent's own summary, an important distinction has been lost.

The system that performed the action has also become the sole source describing its legitimacy.

Recording Actions and Recording Authority Are Different

An execution log may identify a transaction.

An authorisation record may identify the rule or mandate under which the transaction was permitted.

A corporate approval may establish a separate institutional decision.

A receiving service may maintain its own record.

These records can support different questions.

They should not be silently merged into one self-validating account.

The goal is not to require identical records in every system.

It is to preserve sufficient attribution and provenance for the relevant institutional question.

Tamper-Evident Does Not Mean Infallible

Cryptographic protection, append-only storage and independent custody can reduce the risk of unauthorised alteration.

They do not automatically establish that every recorded event is truthful or complete.

A system may preserve inaccurate input.

A logging component may fail to capture an event.

A policy engine may apply an incorrect rule.

A signed mandate may originate from a principal who lacked the claimed authority.

Consequently, protected evidence improves the conditions for later investigation without guaranteeing the substantive validity of the original event.

W3C PROV-O offers a separate technical reference for describing relationships among entities, activities and agents. [7]

Such provenance relationships can assist reconstruction.

They do not independently certify the legitimacy of every activity.

W3C Verifiable Credentials Data Model 2.0 makes a related distinction: verifying a credential does not automatically establish the truth of every claim contained within it. [8]

These distinctions should remain applicable when credentials and provenance records are used in agentic systems.

Historical Validity and Current Authority

An agent's authorisation may expire.

Its credentials may rotate.

Its configuration may change.

The agent may eventually be retired.

These developments should not require historical records to be rewritten.

A later reviewer may need to establish that an agent was authorised for a particular action at the time it occurred, even though that authorisation is no longer valid today.

Current permission and historical attribution are different questions.

An evidence system should preserve that distinction.

Institutional accountability and regulatory context

06 | Accountability Cannot Be Delegated Away by Technical Design

The Institution Remains Part of the Decision

Technical delegation can assign permissions to an AI agent.

It does not automatically determine the allocation of legal or corporate accountability.

Different legal systems, contractual arrangements and governance structures may assign responsibilities differently.

But the existence of an autonomous system does not, by itself, eliminate the responsibilities of the institutions deploying or governing it.

FSB: AI Governance Remains an Institutional Responsibility

The Financial Stability Board's final 2026 Sound Practices emphasise the role of boards and senior management in establishing and overseeing AI governance.

They also address clearly defined responsibilities, risk management, documentation, effective human oversight and third-party dependencies. [3]

The FSB's recommendations are addressed to financial institutions.

They should not be represented as directly binding on every company using an AI agent.

Their broader institutional relevance lies in a clear distinction.

Automated capability may be delegated to technology.

Institutional governance responsibility must still be addressed.

Four Distinct Roles

An enterprise agentic workflow may involve several responsibilities.

Institutional Principal

The organisation or authorised person that determines the original business objective and permitted scope.

Agent Operator or Deployer

The entity responsible for configuring, deploying or operating the agent within an environment.

Tool or Service Provider

The entity operating an application, API, database or external service through which an action occurs.

Competent Reviewer

The person or institution entitled to evaluate whether the relevant action satisfied a particular legal, contractual, governance or assurance requirement.

These roles may overlap.

They may also be distributed among different organisations.

The allocation of responsibility depends on the applicable arrangements.

A technology provider does not automatically assume every responsibility belonging to the enterprise.

Conversely, an enterprise cannot necessarily avoid responsibility merely because an external service performed the technical operation.

Human Oversight Must Be Meaningful

NIST's fifth design tenet proposes risk-based triggers for human intervention.

It also warns about the possibility of approval fatigue, where repeated escalation prompts cause human reviewers to approve actions habitually. [1]

This is an important limitation.

Adding a human confirmation button does not, by itself, establish effective oversight.

The reviewer must have enough relevant information and appropriate authority to make a meaningful decision.

For certain actions, the institution may permit autonomous execution within predefined limits.

For others, explicit review may be necessary.

The appropriate arrangement depends on risk, organisational policy and applicable requirements.

The distinction is between meaningful control and the appearance of control.

Human oversight cannot be inferred merely from the presence of a human interface.

07 | Agentic AI and the Boundaries of Existing Regulation

Different Institutions Are Asking Different Questions

The current developments do not create one global legal regime for autonomous agents.

They address different institutional responsibilities.

NIST: Identity and Authorisation Architecture

NIST's October 2026 design tenets are initial technical proposals.

They concern security architecture, identity, permission management, runtime control and evidence.

They should not be described as mandatory statutory rules or proof of a universally validated implementation.

FSB: Financial-Sector Governance

The FSB's 12 Sound Practices provide non-binding recommendations for financial institutions adopting AI.

Their focus includes strategic oversight, operational risk, human intervention and third-party risk management.

They are not a general legal definition of agent authority.

ICO: Personal-Data Protection and Accountability

The ICO's October 2026 call for evidence examines how existing data protection law should be applied to the distinctive capabilities and risks of agentic AI. [4]

It includes questions concerning transparency, security, automated decisions, purpose limitation and lawful processing.

These are not simply technical authorisation questions.

An agent may be authorised by an enterprise to access a system while the contemplated personal-data processing still requires separate legal assessment.

Institutional permission does not automatically establish a lawful basis for processing personal data.

Likewise, maintaining an extensive activity log does not automatically justify indefinite retention or disclosure of personal information.

Evidence preservation must remain compatible with applicable privacy and data-protection obligations.

EU AI Act: Scope Matters

The EU AI Act contains provisions addressing record-keeping and human oversight for systems within its high-risk AI framework. [9]

These requirements illustrate the significance of operational traceability and human oversight within the applicable legal context.

However, they should not be interpreted as imposing identical requirements on every AI agent merely because it can act autonomously.

Legal applicability depends on the relevant classification, provisions, implementation timing and specific circumstances.

The existence of an agent is not itself a universal high-risk classification.

Technical Standards and Legal Conclusions Must Remain Separate

A technical identity standard may support authentication.

An authorisation protocol may express delegated permissions.

A provenance model may describe how an action or artifact was generated.

A governance framework may recommend oversight and accountability controls.

None of these mechanisms, by itself, determines every legal consequence of an autonomous action.

Technical validity is an important form of evidence.

It is not a universal substitute for institutional or legal judgment.

One agent, multiple authority boundaries

08 | One Agent, Multiple Authority Boundaries

A Hypothetical Procurement Scenario

Consider an enterprise deploying an AI procurement agent.

The enterprise permits the agent to identify approved suppliers and create purchase orders within defined limits.

The agent has a distinct technical identity.

Its mandate specifies eligible suppliers, transaction limits, permitted tools and relevant escalation conditions.

An independent policy mechanism evaluates proposed actions.

A protected record captures relevant events.

This arrangement may be appropriately designed.

But its effectiveness depends on how it responds to different circumstances.

Scenario A | Action Within Scope

The agent selects an approved supplier and submits a purchase order within the permitted amount.

The relevant authorisation remains valid.

The policy mechanism permits the action.

The procurement service accepts the request.

What may be established: The action was executed within the recorded technical authorisation conditions.

What remains unresolved: Whether the order produced the intended commercial benefit or goods were subsequently delivered.

Scenario B | Exceeding the Delegated Limit

The agent attempts to submit a purchase order above its permitted threshold.

Its identity remains valid.

But the proposed amount exceeds the mandate.

The policy mechanism denies the action or requires additional approval.

What may be established: The attempted action exceeded the recorded permission boundary and was subject to an appropriate control decision.

What remains unresolved: Whether a separately authorised person later approved the transaction.

Scenario C | Expired or Revoked Authority

An agent attempts an action after its relevant authorisation has expired or been withdrawn.

The agent may still possess technical credentials.

But the applicable institutional mandate is no longer valid.

The requested action should be evaluated against the current authorisation state.

What may be established: The validity of a credential and the validity of the underlying mandate are separate questions.

Scenario D | Untrusted Instructions Change the Task

The agent processes external supplier information containing instructions to redirect payment details.

The external content is not an authorised enterprise instruction.

It should not independently change the agent's mandate.

What may be established: A trustworthy policy boundary must distinguish task-authorising instructions from untrusted operational data.

What remains unresolved: Whether every such manipulation attempt can be detected under all circumstances.

Scenario E | Downstream Authority Expansion

The primary agent delegates research to another agent.

The downstream agent attempts to access restricted financial information outside the delegated task.

The downstream agent's authority cannot be inferred merely from the primary agent's broader technical environment.

What may be established: Delegated permission must remain bounded and attributable through the relevant chain.

Scenario F | Technical Execution Without Sufficient Authority

A receiving application accepts an action that should have been denied under the enterprise's institutional restrictions.

The transaction succeeds technically.

The evidence records the request and response.

What may be established: A technical execution occurred.

What cannot be concluded automatically: That the action was institutionally authorised, legally valid or consistent with the applicable governance framework.

This last scenario illustrates the core problem.

A successful operation and a valid authorisation are different facts.

An accurate execution log does not transform an unauthorised action into an authorised one.

PDEI conditions, evidence limits and research propositions

09 | The Pre-Disclosure Evidence Infrastructure Perspective

The Evidence of Authority Must Exist Before the Action Is Interpreted

The preceding analysis identifies several distinct institutional events.

A task is initiated.

Authority is delegated.

An agent receives or uses credentials.

A proposed action is generated.

An authorisation decision is made.

A tool operation is attempted or completed.

A result is recorded.

Subsequent review determines what the evidence supports.

These events may be generated and recorded by different systems.

A single agent may not control all of them.

That separation can be valuable for institutional accountability.

Identity

The relevant agent, principal, operator, resource and action must remain distinguishable.

An agent's logical identity should not be confused with its current credential, runtime instance or human task originator.

Identity enables attribution.

It does not independently establish authority.

Provenance

The origins of mandates, authorisation decisions, execution requests and results should remain identifiable to the extent necessary for legitimate review.

A later investigator may need to understand which source generated a statement or artifact and whether it was subsequently modified.

Provenance supports reconstruction.

It does not guarantee the truth of the recorded content.

Authority

The institution granting permission, the scope of the permission and the entity enforcing the relevant decision must remain distinguishable.

An agent may propose actions.

An authorisation mechanism may permit or deny them.

An enterprise may remain responsible for the governance of the delegated process.

Those functions must not be collapsed.

Continuity

Agent configurations, credentials, policies, organisational roles and mandates may change.

Historical evidence should remain attributable to the conditions applicable at the time of the relevant action.

A current credential should not be treated as proof of earlier authorisation.

An expired mandate should not erase a valid historical attribution.

A changed policy should not silently rewrite the record of an earlier decision.

Boundary

Evidence must retain the limits of what it establishes.

An identity record may establish which agent was identified.

A mandate may establish the scope of a recorded delegation, subject to the authority of its issuer.

A policy decision may establish that the configured control permitted an action.

A tool log may establish that a request was processed.

An institutional review may determine whether the action was legitimate for its specific purpose.

These are not equivalent conclusions.

What PDEI Can and Cannot Contribute

The Pre-Disclosure Evidence Infrastructure perspective does not replace identity-management standards, access-control systems, AI risk management, legal authorisation or professional review.

It examines the relationships that need to remain attributable and interpretable before information can support subsequent institutional conclusions.

Applied to agentic AI, its possible contribution is to distinguish:

Evidence of Identity

from

Evidence of Delegation

from

Evidence of Authorisation

from

Evidence of Execution

from

Evidence of Institutional Review.

The stages need not form one mandatory technical sequence.

Different systems may implement them differently.

Their evidentiary meanings should nevertheless remain distinct.

The agent may execute an action.

The authority governing that action must remain independently examinable.

10 | What an Autonomous Evidence History Cannot Prove

More Logs Do Not Automatically Mean More Accountability

Agentic systems may generate substantial volumes of operational information.

Every tool call may produce a log.

Every action may receive a timestamp.

Every permission check may generate an event.

Every interaction may create additional metadata.

This can improve visibility.

It can also create new governance problems.

An Incomplete Log Can Appear Complete

A record may accurately capture the events visible to one service while omitting actions performed elsewhere.

A later reviewer must understand the scope of the logging system.

Tamper Resistance Does Not Establish Correctness

An append-only record may preserve an incorrect event description.

Technical integrity and factual reliability are different properties.

A Signed Mandate May Be Institutionally Defective

A mandate may be digitally signed by a valid credential.

But the issuer may lack authority for the relevant corporate action.

The signature does not independently resolve the governance question.

A Policy Decision Can Apply the Wrong Policy

A deterministic authorisation mechanism can consistently apply incorrect rules.

Its consistency does not establish that the rules were appropriate.

Human Approval Can Become Formalistic

Frequent requests for human confirmation may create approval fatigue.

A recorded approval does not independently establish meaningful oversight.

Privacy Can Be Compromised by Excessive Evidence Collection

Comprehensive logging may capture personal information, confidential documents, sensitive business instructions or third-party data.

Evidence retention should therefore remain subject to applicable purpose, access, security and retention controls.

A Technically Authorised Action May Produce an Unacceptable Outcome

An action may be within its delegated limits yet produce financial loss, operational harm or a legally disputed result.

Technical authorisation is not a universal determination of appropriateness or outcome.

These limitations illustrate why evidence infrastructure should not be evaluated solely by the volume of recorded events.

The relevant objective is not to prove that the system logged everything.

It is to preserve sufficient evidence for the institutional questions the system may legitimately need to answer.

11 | Research Propositions for Autonomous Institutional Evidence

The developments examined in this publication support several testable research questions.

They do not establish that any particular technical architecture has already solved agentic accountability.

H1 | Authority Attribution

Can a verifiable relationship among institutional principals, agent identities, delegated mandates and runtime decisions improve the reconstruction of who authorised a particular autonomous action?

H2 | Scope Preservation

Can explicit delegation constraints reduce the frequency of actions performed outside the originally intended authority?

H3 | Independent Evidence Integrity

Can protected, agent-independent activity records improve the ability to detect, investigate or reconstruct unauthorised execution and control failures?

H4 | Use-Time Authority Validation

Can current authorisation checks reduce reliance on expired, revoked or contextually invalid permissions?

H5 | Institutional Accountability

Can clearer separation of task originators, agent operators, tool providers and reviewers improve the attribution of responsibility during consequential autonomous workflows?

These hypotheses require empirical evaluation.

Relevant observations might concern unauthorised tool calls, incorrect permission decisions, unresolved attribution, incident reconstruction time, oversight quality and the effect of control design on legitimate task completion.

The analysis must also allow contrary findings.

Stronger controls may impose additional latency.

Excessive escalation may reduce usability and encourage habitual approvals.

Overly detailed logging may create privacy and security risks.

Complex delegation infrastructure may introduce new failure points.

Evidence quality may remain poor even when record integrity is high.

An effective design must balance traceability, control, operational practicality and the actual risks associated with the use case.

The research objective is not to demonstrate that more evidence is invariably better.

It is to establish whether the evidence retained supports meaningful institutional control and accountability.

Closing Reflection, Methodological Boundary and Sources

Closing Reflection

The Agent Can Act. Who Authorised the Action?

Autonomous agents introduce a new form of institutional distance.

A person or organisation may define an objective.

An AI system may interpret the objective.

A connected tool may execute a transaction.

Another service may preserve the result.

A reviewer may examine the action later.

The action can move through several systems without the original task originator being present at every step.

That distance does not eliminate institutional responsibility.

It makes the relationship between technical capability and delegated authority more important.

An agent can be authenticated.

Its credentials can be valid.

Its tool requests can succeed.

Its activity logs can remain intact.

Yet an institution may still need to determine whether the action was authorised for the relevant purpose, within the applicable scope and under the conditions existing at the time.

NIST's emerging agent identity design principles, the FSB's financial-sector governance practices and the ICO's continuing consultation address different parts of this problem.

They do not establish one global authorisation standard.

But their combined relevance points towards a deeper evidence question.

As autonomous execution becomes more capable, the institution must retain the ability to distinguish what a system could do from what it was authorised to do.

That distinction cannot be resolved by identity alone.

It cannot be resolved by a signed credential alone.

And it cannot be resolved by the existence of a successful transaction record.

The necessary evidence concerns the relationships among the institutional principal, the delegated mandate, the executing agent, the applicable policy, the actual operation and the responsible reviewer.

Those relationships must remain identifiable and subject to legitimate examination.

Identity establishes which agent acted.

Delegation defines the authority it was given.

Execution records what the system actually did.

Institutional accountability determines how that action must be evaluated.

The agent is not the authority.

The authority must remain provable beyond the agent.

Methodological Boundary

This publication presents an independent institutional analysis of emerging agentic AI identity, authorisation, governance and accountability developments.

The analysis is principally informed by NIST's October 2026 initial design tenets, the FSB's October 2026 final Sound Practices, the UK ICO's ongoing call for evidence and established technical specifications concerning identity, delegation and provenance.

The institutional status of these sources differs.

NIST's ten design tenets are preliminary technical proposals published in a blog, not mandatory regulations or a final agent identity standard.

The FSB's Sound Practices are non-binding recommendations for financial institutions.

The ICO's call for evidence remains open until 20 November 2026 and has not produced final additional guidance.

IETF RFC 8693 provides technical mechanisms for token exchange, impersonation and delegation. It does not determine corporate legal authority.

W3C PROV-O provides a model for representing provenance relationships. It does not certify the truth, legality or adequacy of the activities represented.

W3C Verifiable Credentials Data Model 2.0 explicitly distinguishes credential verifiability from the truth of the claims contained within a credential.

References to the EU AI Act concern requirements applicable within its defined scope. They are not presented as universal requirements imposed on all autonomous agents.

The analytical distinction between Agent Identity, Delegated Authority, Autonomous Execution and Institutional Accountability is developed for this publication.

The models in Figures 1 and 2 are original editorial interpretations and do not represent mandatory international authorisation workflows.

The hypothetical procurement scenarios are illustrative, not documented real-world incidents.

The publication does not claim that a digital signature, technical credential, policy-engine decision, protected log or complete provenance chain independently establishes lawful authority, contractual validity, regulatory compliance or an acceptable outcome.

Nor does it establish that every autonomous action requires explicit human approval.

The appropriate controls depend on the institutional context, nature of the activity, delegated authority, applicable requirements and relevant risks.

The existing Pre-Disclosure Evidence Infrastructure conditions of Identity, Provenance, Authority, Continuity and Boundary are an independent institutional research framework developed by EMJ.LIFE.

They are not terminology issued or endorsed by the external institutions cited.

No independent assurance, regulatory approval, legal determination or commercial product endorsement is implied.

Official External Sources and Research References

Agent Identity and Authorisation

[1] National Institute of Standards and Technology (27 October 2026).

Design Tenets for Agent Identity Management Systems.

NIST Cybersecurity Insights.

Initial proposals covering ten design principles for agent identity, delegation, authorisation, policy separation, continuous monitoring and independently retained evidence.

https://www.nist.gov/blogs/cybersecurity-insights/design-tenets-agent-identity-management-systems

[2] NIST National Cybersecurity Center of Excellence (29 September 2026).

Comments on Software and Agentic SI Identity Concept Paper.

Includes development of practical demonstration use cases for identity, authentication and authorisation of AI agents within software development workflows.

https://www.nccoe.nist.gov/news-insights/comments-software-and-agentic-si-identity-concept-paper

[3] Financial Stability Board (15 October 2026).

Sound Practices for Responsible Adoption of Artificial Intelligence: Final Report.

Twelve non-binding sound practices addressing financial-sector AI governance, accountability, documentation, oversight and risk management.

https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/

Data Protection and Agentic AI

[4] UK Information Commissioner's Office (8 October 2026).

Agentic AI Call for Evidence.

Public consultation concerning security, transparency, accountability, automated decision-making, purpose limitation and lawful processing.

Closing date: 20 November 2026.

https://ico.org.uk/AgenticAI

Technical Delegation and Access Control

[5] NIST (2020).

NIST Special Publication 800-207: Zero Trust Architecture.

Establishes technical distinctions concerning authentication, authorisation and access-control architecture.

https://csrc.nist.gov/pubs/sp/800/207/final

[6] Internet Engineering Task Force (2020).

RFC 8693: OAuth 2.0 Token Exchange.

Defines token-exchange mechanisms and the representation of impersonation and delegation relationships.

https://datatracker.ietf.org/doc/html/rfc8693

Provenance and Verifiable Assertions

[7] World Wide Web Consortium (2013).

PROV-O: The PROV Ontology.

W3C Recommendation providing a formal model for provenance relationships among entities, activities and agents.

https://www.w3.org/TR/prov-o/

[8] World Wide Web Consortium (15 May 2025).

Verifiable Credentials Data Model v2.0.

W3C Recommendation distinguishing credential verification from the validity and truth of the claims being assessed.

https://www.w3.org/TR/vc-data-model-2.0/

Regulatory Context

[9] European Union.

Regulation (EU) 2024/1689, Artificial Intelligence Act.

Particularly Article 12 on record-keeping and Article 14 on human oversight for relevant high-risk AI systems, subject to scope and applicable legal provisions.

https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Related Institutional Framework and Research Continuity

The following publications provide methodological continuity. They are not independent external validation of the propositions developed in this analysis.

Pre-Disclosure Evidence Infrastructure

The existing institutional framework distinguishes Identity, Provenance, Authority, Continuity and Boundary as five evidence-governance conditions.

https://www.sustainabilitynewsnetwork.net/pre-disclosure-evidence-infrastructure

Evidence Infrastructure Analysis · 010

AFTER DEPLOYMENT

Examined how evidence validity may change following deployment and why continuous evidence relationships are relevant to changing AI systems.

https://www.sustainabilitynewsnetwork.net/article/after-deployment

Evidence Infrastructure Analysis · 014

INTEROPERABILITY IS NOT BINARY

Examined why technical interoperability and institutional validity are different conditions.

Evidence Infrastructure Analysis · 015

WHEN EVIDENCE BECOMES EXECUTABLE

Examined structured evidence participating in defined procurement verification and eligibility decision processes.

https://www.sustainabilitynewsnetwork.net/article/when-evidence-becomes-executable

EIA-025 addresses a different question: whether an autonomous system performing an enterprise action possesses the authority required for that particular action.

Evidence Infrastructure Analysis · 022

ONE ENTITY, MULTI EVIDENCE HISTORIES

Examined the continuity of independently governed corporate evidence histories under a common legal-entity identity.

https://www.sustainabilitynewsnetwork.net/article/one-entity-multi-evidence-histories

Evidence Infrastructure Analysis · 023

WHEN EVIDENCE IS NEEDED

Examined why preserved evidence must still be evaluated for a particular institutional purpose.

https://www.sustainabilitynewsnetwork.net/article/when-evidence-is-needed

EIA-025 applies that discipline to autonomous execution, distinguishing the evidence of identity, delegation, authorisation, action and accountability.

Publisher: EMJ.LIFE | Singapore

Research Classification: Autonomous AI Governance and Institutional Evidence Analysis

Research Perspective: Pre-Disclosure Evidence Infrastructure