Resolving the Actor: How to Track What an Agent Accessed vs. What a Human Intended

Date: 05 November 2026

Executive Summary

AI agents can act across APIs, files, databases, browsers, and business systems. The person who initiated a task may be easy to identify, but that does not prove what the person intended, what the agent attempted, what the policy allowed, or what data the agent actually accessed.

That gap creates a material security and compliance problem. An incident record that says “user A accessed customer records” may conceal an agent-generated query, an overly broad service identity, a tool wrapper that bypassed policy, or a response assembled from data the user never requested.

The security decision is clear: treat human intent, agent execution, authorization, and resource access as separate events. Build an evidence chain that connects them without collapsing them into one identity. If your platform cannot reconstruct that chain, restrict agent permissions until it can.

Contents

• The Attribution Problem
• Reference Architecture and Trust Boundaries
• Tracking the Full Tool-Call Flow
• Controls That Preserve Intent and Evidence
• Implementation Guidance
• Risks and Mitigations
• Deployment Checklist
• Frequently Asked Questions

The Attribution Problem

Traditional access logs often assume a simple model: a human authenticates, the human requests a resource, and the system records the human identity. Agentic systems break that assumption.

A typical request may involve a human, a chat interface, an orchestration service, a model, one or more tools, delegated credentials, and downstream systems. Each component can make a decision or transform the request. The final database query may bear little resemblance to the original natural-language instruction.

Four questions must remain distinct:

• Authentication: Which principal presented valid credentials?
• Authorization: Was that principal permitted to perform this action on this resource?
• Policy enforcement: Which rules evaluated the request, and where was the request allowed, modified, or denied?
• Auditability: Can an investigator reconstruct the request, decisions, actions, results, and evidence later?

Authentication does not establish intent. Authorization does not prove that the agent used the minimum necessary data. A policy decision does not show whether a tool actually enforced it. An audit log is useful only if it captures enough context to connect these facts.

Reference Architecture and Trust Boundaries

A governed agent system should model at least five identities:

• Human principal: The authenticated person or workforce identity that initiated or approved a task.
• Session or conversation: The bounded interaction in which the task was described and decisions were made.
• Agent execution: A unique run, including model version, system instructions, delegated scope, and execution state.
• Tool invocation: A specific call made by the agent, with arguments, policy results, and timing.
• Downstream principal: The identity presented to the target service, such as a short-lived token, workload identity, or constrained service account.

These identities should be linked with immutable identifiers, not inferred from usernames or log message text. A useful relationship is:

human_id -> session_id -> agent_run_id -> tool_call_id -> downstream_request_id -> resource_event_id

Each arrow represents correlation, not identity substitution. The downstream service should know that a request was made on behalf of a human through an agent, while still recording the actual credential used for the request.

Trust Boundaries

Common trust boundaries include the user interface, the agent runtime, the model provider, the tool gateway, and each downstream system. Treat model output as untrusted input. A model can propose an action, but it should not be the component that grants itself access.

The tool gateway is a key enforcement point. It should validate the requested operation, resource, data classification, purpose, approval state, and token scope before forwarding the call. Downstream systems must still enforce their own authorization. A gateway is not a substitute for resource-level controls.

Assume that prompts, retrieved documents, tool results, and model-generated arguments can contain malicious or misleading instructions. Prompt injection is one failure mode, but the broader issue is confused delegation: data returned to the agent can influence a later action unless the runtime applies independent policy checks.

Tracking the Full Tool-Call Flow

Consider a human instruction: “Find the outstanding invoices for our European accounts and prepare a summary.” That instruction does not authorize every query the agent might construct.

A traceable flow should record the following:

1. The interface authenticates the human and creates a session with a defined tenant, purpose, and expiry.
2. The orchestrator creates an agent run and records the model, policy version, system configuration identifier, and allowed tools.
3. The model proposes a tool call. The proposal is treated as a request, not as an authorization.
4. The policy engine evaluates the tool, arguments, resource scope, data classification, and human approval requirements.
5. The tool gateway either denies, modifies, requests approval, or executes the call using a constrained downstream credential.
6. The downstream system records the actual operation, resource identifiers, rows or objects returned where practical, and its own authorization result.
7. The runtime records the tool result and whether the result was shown to the human, transformed, stored, or used to trigger another action.

The distinction between intended, attempted, authorized, and completed is essential. A query may be proposed but denied. It may be authorized but return no records. It may return records that were never displayed to the user but were used in a later model prompt. These are different security facts.

Failure Modes

• Identity collapse: Every event is attributed only to the human, hiding agent behavior.
• Service-account overreach: The agent uses a broad credential that is more powerful than the human’s effective rights.
• Argument drift: The natural-language task is narrow, but generated filters or identifiers expand the query.
• Unlogged transformation: A tool wrapper silently enriches or rewrites the request.
• Result leakage: Sensitive tool output enters prompts, caches, traces, or model-provider logs without a defined handling policy.
• Replay ambiguity: An investigator cannot determine whether a recorded tool call was executed once, retried, or partially completed.

Controls That Preserve Intent and Evidence

Start with a request envelope that travels through the system. It should contain the human principal, session, purpose, tenant, requested action, approved scope, and expiration. The agent can add a proposed action, but it should not be able to alter the original intent fields.

Use short-lived, audience-restricted credentials for downstream calls. Bind them to the agent run and tool scope where the platform supports it. Avoid passing a long-lived user token into prompts, tool arguments, or general-purpose runtime state.

Require step-up approval for actions that change state, disclose restricted data, send external communications, or create durable consequences. Approval should cover the exact operation and resource scope. “Approve this task” is weaker than “Approve deletion of object 4821 in tenant northwind.”

Log decisions at every enforcement point. A denial should include the policy rule, decision input references, and reason code. An approval should include the approver, timestamp, expiry, and approved scope. Do not record secrets or unrestricted sensitive payloads merely because they are available in memory.

Protect audit records from alteration. Use an append-oriented store, access controls separated from the agent runtime, clock synchronization, retention rules based on documented business needs, and alerting for gaps or unexpected changes. The exact retention period is an organizational decision unless a specific contract or legal obligation requires otherwise.

Implementation Guidance

Illustrative Request Envelope

{
  "human_id": "user-1842",
  "session_id": "sess-77c2",
  "agent_run_id": "run-91af",
  "purpose": "invoice_summary",
  "tenant": "northwind-eu",
  "approved_scope": {
    "resources": ["invoices"],
    "regions": ["EU"],
    "actions": ["read"]
  },
  "expires_at": "2026-11-05T16:00:00Z",
  "trace_id": "trace-a81e"
}

Illustrative example: The envelope is a design pattern, not a claim about a required industry standard. Field names and controls should match the systems that implement them.

Illustrative Policy Decision

decision = policy.evaluate({
  principal: request.human_id,
  agent_run: request.agent_run_id,
  tool: "invoice.search",
  action: "read",
  tenant: request.tenant,
  arguments: normalized_arguments,
  purpose: request.purpose,
  approved_scope: request.approved_scope
})

if decision.effect != "allow":
    audit.record("tool_denied", decision)
    return require_approval_or_stop(decision)

downstream_token = token.issue(
  subject=request.agent_run_id,
  audience="billing-api",
  scope=["invoice:read"],
  resource_filter=decision.resource_filter,
  expires_in_seconds=300
)

return tool.execute(token=downstream_token, trace_id=request.trace_id)

Normalize and validate arguments before authorization. For example, convert free-text region names into a controlled set, reject unknown tenant identifiers, and prevent the model from supplying arbitrary fields to a query builder. The downstream service should apply the final resource filter rather than trusting the gateway’s intent.

Minimum Observability Fields

• Human, session, agent run, tool call, downstream request, and trace identifiers.
• Authentication method and credential or token type, without secret material.
• Model and agent configuration identifiers.
• Original user instruction reference and normalized purpose.
• Proposed tool, normalized arguments, policy version, and decision.
• Approval details, if required.
• Execution status, retry count, result classification, and downstream authorization result.
• Data handling events, including display, storage, onward transmission, or deletion.

Capture content selectively. Full prompts and results can help investigations, but they can also create a second sensitive-data repository. Prefer structured metadata, redaction, hashes, sampled payloads, and controlled forensic access where full content is not necessary.

Risks and Mitigations

Risk	What fails	Mitigation
Human and agent identities are merged	Investigators cannot separate intent from execution	Use linked, immutable identifiers for every identity and action layer
Broad delegated credentials	The agent can access more than the human task requires	Issue short-lived, scoped credentials with resource filters
Prompt injection changes tool behavior	Untrusted content influences later actions	Treat model output and retrieved content as untrusted; reauthorize every tool call
Policy decisions are not recorded	Access appears unexplained or impossible to investigate	Log policy inputs, version, result, reason, and enforcement point
Tool results enter uncontrolled stores	Sensitive data spreads through prompts, traces, or caches	Classify results, redact where possible, and define storage and retention controls
Retries are invisible	Teams cannot tell whether an action happened once or several times	Use idempotency keys and record attempt, completion, and retry state

Deployment Checklist

• Define separate identifiers for human intent, session, agent run, tool call, and downstream request.
• Document every trust boundary and identify the component that enforces each policy.
• Inventory agent tools, data sources, credentials, side effects, and failure behavior.
• Require explicit purpose and tenant context for sensitive operations.
• Authorize normalized tool arguments, not only the original prompt.
• Use short-lived downstream credentials with narrow audience and scope.
• Set approval thresholds for data disclosure and state-changing actions.
• Record allow, deny, modify, approval, retry, and completion events.
• Test prompt injection, argument expansion, confused-deputy behavior, and credential misuse.
• Review whether logs and traces themselves contain sensitive data.
• Run reconstruction exercises using only production evidence, then close missing links.

Frequently Asked Questions

Should the agent use the human’s identity?

It should preserve the human identity as the initiator or delegator, but downstream systems should also identify the agent execution and actual credential used. One identity should not replace the others.

Is a prompt log enough to prove what the agent accessed?

No. A prompt shows an instruction or context, not a completed operation. You need tool-call records and downstream resource events to prove what was requested and accessed.

What if the agent only has read access?

Read-only access reduces some risks but does not eliminate data exposure, aggregation, inference, or unauthorized disclosure. Read operations still require scope, purpose, and audit controls.

Should every tool result be stored in full?

No. Full capture may increase exposure. Store the minimum evidence needed for detection and investigation, with controlled access to additional content when justified.

How can we detect that intent and access diverged?

Compare the original purpose and approved scope with normalized arguments, policy decisions, and returned resources. Alert on scope expansion, unexpected tenants, unusual data classifications, or tool sequences outside the task plan.

Where should policy enforcement happen?

At the tool gateway and again in the downstream service. The gateway understands agent context; the resource-owning service is the final authority over its data.

Does this design guarantee compliance?

No. It creates evidence and control points that support risk management. Compliance depends on your jurisdiction, contracts, data, policies, and documented obligations. Do not treat an architecture pattern as legal advice.

What is the first practical improvement?

Trace one high-risk workflow end to end. Separate its human, agent, tool, and downstream identities, then verify that a reviewer can reconstruct an allowed and a denied request from the recorded evidence.

Conclusion

Agent security depends on resolving the actor without oversimplifying the action. The human may start the task, the model may propose a call, the policy engine may permit it, the tool gateway may transform it, and the downstream service may execute it. Those are separate events with separate security meanings.

Organizations that preserve those distinctions can investigate incidents, limit delegation, test controls, and make better decisions about where agents may operate. Organizations that collapse them into a single user identity will struggle to prove what happened.

Ready to govern AI-agent access with clearer identity, policy, and audit evidence? Use AXEC for governed AI-agent security and schedule a 30-minute meeting at https://cal.id/axec/demo?duration=30.