Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-actor-recorder-split

Separation of actor and recorder — different identities for action and audit

An agent that writes its own audit log can omit, alter, or suppress any record of its own actions. This is not a theoretical risk: an attacker who controls the acting identity controls the evidence. Actor/recorder separation is the structural fix. The identity that performs an action and the identity that records it are different principals, with non-overlapping permissions, so no single compromise can both execute and erase.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node
Restricted to node kinds: audit-log
COVERAGE
4 threats
T8 · T23 · T35 · T44
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • The identity that acts and the identity that writes the audit record must be different principals: the actor holds no write access to its own audit log.
  • The recorder identity uses append-only or WORM storage, so a compromised actor cannot delete, alter, or suppress its own entries after the fact.
  • Transport separation ensures audit records travel over a path the actor cannot interfere with: cloud-native platform audit trails (CloudTrail, GCP Cloud Audit Logs) or a side-channel queue the actor cannot modify.
  • Without this split, any attacker who controls the actor controls the record, making repudiation, log tampering, and selective evidence suppression structurally possible.

How it behaves

Agent takes an action (tool call, API request, state mutation)
Does the recorder identity (not the actor) have sole write access to the audit log?
Audit entry written by recorder; actor cannot suppress or alter it
Structural violation: stop and remediate before proceeding
This is a design-time structural check, not a runtime decision; the separation must be enforced at the IAM or identity layer, not in application code.

What it is

Separation of duties, applied to logging, means the identity that takes an action cannot be the same identity that records it. Without that separation, the audit log is only as trustworthy as the acting agent: a compromised or malicious actor can write, modify, or delete its own records, and the audit trail becomes unreliable as evidence.

The fix is structural. The actor identity holds no write access to audit storage. A separate recorder identity holds append-only access to the audit log and is the only principal that can write entries. An attacker who controls the actor cannot reach the recorder's write path, and cannot therefore suppress or falsify the record of the actor's actions.

Three implementation layers work together:

  1. Identity separation: actor and recorder are distinct principals with non-overlapping permissions at the IAM or access-control layer.
  2. Transport separation: audit records travel over a path the actor cannot interfere with: a cloud-native platform audit trail such as CloudTrail or GCP Cloud Audit Logs, or a side-channel queue the actor cannot publish to or modify.
  3. Storage separation: WORM (write-once-read-many) storage with an immutability lock, or a hash-chained append-only log, so entries that have been written cannot be overwritten or deleted for the retention period.

Detection signals

  • Audit write-path failures for the recorder identity. Repeated or sustained failures indicate the recorder is degraded or unreachable, which means the audit trail has gaps.
  • Actor identity holding write permission on its own audit storage. This is a policy compliance violation; the separation has not been enforced.

Threats it covers

  • T8 Repudiation and Untraceability −1 severity step

    WHY IT HELPS Repudiation relies on an agent or attacker being able to alter or omit audit records after the fact. Actor/recorder separation removes that capability structurally: the actor identity holds no write access to audit storage, so it cannot delete or modify the entries that document its own actions.

  • T23 Selective Log Manipulation −2 severity steps

    WHY IT HELPS Selective log manipulation is the deliberate suppression or falsification of an agent's own action records. When the actor identity has no write access to audit storage, that manipulation is structurally blocked: a separate recorder principal holds the sole append-only write path, so the actor cannot remove or alter the entries that incriminate it.

  • T35 Manipulation of Proof of Sampling (PoSP) −1 severity step

    WHY IT HELPS PoSP Manipulation depends on an attacker being able to falsify or suppress verification records produced by the PoSP-reporting agent. Actor/recorder separation ensures the agent that submits PoSP claims cannot write to its own attestation log: the recorder identity captures every claim independently, making retroactive falsification of the verification record structurally infeasible.

  • T44 Insufficient Logging in MCP Server / Client −1 severity step

    WHY IT HELPS Insufficient audit coverage in MCP contexts is partially addressed by this control: the recorder identity is responsible for comprehensive action capture independent of what the acting agent reports. Even a compromised actor cannot suppress the recorder's audit entries, because the actor holds no write access to the audit store.

Principle coverage

Defence-in-Depth stage: Detect — and it advances:

  • Separation of Duties Separation of duties requires that no single identity hold enough authority to both perform and record a consequential action. Actor/recorder separation enforces that requirement at the audit layer: the acting identity and the recording identity are distinct principals with non-overlapping permissions, so neither a compromised actor nor a deliberate insider can suppress the evidence of its own actions.
  • Observability / Non-repudiation Observability depends on audit records that accurately reflect what the system did. When the actor and recorder are the same identity, those records can be selectively omitted or falsified; splitting the identities makes the audit trail a reliable, tamper-evident source for detection, investigation, and compliance review.
  • Accountability Accountability requires that every consequential agent action be attributable and non-repudiable. Actor/recorder separation removes the structural condition under which repudiation is possible: because the actor cannot write to its own audit log, it cannot delete or alter the entries that bind its actions to its identity.
  • Transparency / Explainability Transparency toward auditors and oversight processes depends on audit records that the audited entity cannot modify. Keeping the recorder identity separate from the actor identity is the structural guarantee that the record reaching reviewers reflects what actually occurred, rather than what the actor chose to report.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Four implementation patterns, each with a different trust model and operational cost. Cloud-native platform audit (CloudTrail organization trail, GCP organization sink) is the default for cloud workloads because the platform writes records the agent cannot reach. S3 Object Lock and Vault append-only audit are the storage-layer complement. The sidecar pattern covers runtimes where no cloud-native audit trail captures the agent's action surface.

AWS CloudTrail org trail An organization trail in the AWS management account delivers every member-account API call to an S3 bucket in a separate log-archive account. Member accounts, including the account running the agent, can see the trail but cannot delete it, disable logging, or modify its configuration.

Why choose it: Best for AWS-native agentic workloads. Identity separation is structural and enforced by AWS Organizations: member accounts cannot remove or modify the organization trail. The log-archive S3 bucket is in a separate AWS account the agent role has no access to. Pair with S3 Object Lock (COMPLIANCE mode) on the archive bucket and CloudTrail log file integrity validation (SHA-256 hash chains) for the storage-immutability layer.

More details:

AWS S3 Object Lock Enabling S3 Object Lock in COMPLIANCE mode on the audit bucket means a protected object version cannot be overwritten or deleted by any user, including the root user, for the duration of the retention period.

Why choose it: Best as the storage-layer complement to any audit-identity pattern. The actor role is denied all access to the audit bucket in IAM; COMPLIANCE mode provides a second structural guarantee at the storage API level: even if the IAM deny is misconfigured, the retention lock prevents deletion before the period expires. Cohasset Associates has assessed S3 Object Lock for SEC 17a-4, CFTC, and FINRA compliance. Use 7-year COMPLIANCE retention for regulated environments; 90 days minimum for forensic investigations.

More details:

GCP Cloud Logging org sink An aggregated sink at the organization level routes audit log entries from all child projects to a destination bucket in a separate project. The sink's writerIdentity is a Logging-managed service agent, distinct from any application service account.

Why choose it: Best for GCP-native agentic workloads. The writerIdentity that writes entries to the destination project is owned by the platform, not the agent's service account. The source project has no principal with write access to the destination log bucket; the agent cannot interfere with records at the destination. Use an organization-level sink rather than a per-project sink so a compromised agent that acquires owner access to its own project cannot modify the sink definition. Enable destination bucket retention locks for WORM-equivalent immutability.

More details:

HashiCorp Vault audit devices Vault sends every API request and response to all enabled audit devices and refuses to service the corresponding API request if it cannot log to at least one enabled device. File audit devices append sequentially; no Vault API permits deletion or modification of existing audit entries.

Why choose it: Best for agentic workloads that use Vault for secrets retrieval and need the secrets-access audit trail to be tamper-evident. The recorder is the Vault server process, a distinct identity and process from the agent. The agent cannot call any Vault API to delete its own audit entries. The fail-closed behavior is the key agentic property: a compromised actor that disrupts the audit device path causes Vault to become unavailable rather than silently dropping records. Pair with a log-shipping sidecar (fluentd, vector) that forwards audit output to a write-isolated destination.

More details:

Sidecar audit emitter A dedicated sidecar process runs alongside the agent container, intercepts action events over a local socket, and forwards them to audit storage using its own workload identity. The actor container's IAM role is explicitly denied all access to audit storage; only the sidecar identity holds the write permission.

Why choose it: The only option when no cloud-native platform audit covers the agent's action surface: agents that call internal APIs or take file-system actions that do not appear in CloudTrail or GCP Audit Logs. The sidecar identity (a separate service account, SPIFFE SVID, or Kubernetes service account) holds append-only access to audit storage; the actor identity carries an explicit deny on that resource. This is a self-build pattern with no off-the-shelf product; it requires designing the inter-process trust boundary, preventing the actor from killing or reconfiguring the sidecar, and ensuring the sidecar identity is rotated.

More details:

Trade-offs

  • For cloud-native options (CloudTrail organization trail, GCP organization sink), there is no latency cost on the action path: the platform writes audit records asynchronously and independently of the agent's API calls. The only overhead is the deny IAM policy that blocks the actor from audit storage, which adds no measurable latency.
  • S3 Object Lock COMPLIANCE mode is irreversible for the retention period; setting the wrong retention is an operational error with no recourse short of deleting the AWS account. Test with GOVERNANCE mode first, then migrate to COMPLIANCE for production.
  • The sidecar pattern adds operational complexity: you must prevent the actor container from sending SIGKILL to the sidecar, ensure the sidecar restarts before the actor restarts, and instrument the sidecar's health independently. A sidecar crash that silently drops audit events is harder to detect than a write-permission error.
  • Dev effort is medium and concentrated at the IAM and identity layer: the code to use the audit trail is straightforward; the substantive work is auditing every path where the actor identity is granted or denied permissions to confirm that the separation holds across all environments.

When NOT to use

  • Skip for agents running in a single serverless function with no persistent audit store and no state mutations: the overhead of a separate recorder identity exceeds the value when there is nothing persistent to tamper with.
  • Skip for read-only advisory agents with no consequential actions and negligible repudiation risk; the identity split adds IAM complexity that is not justified when the agent cannot act.
  • Do not apply the sidecar pattern to single-developer or hobby deployments: use CloudTrail or GCP Audit Logs directly, which provide recorder separation at no additional operational overhead.

Limitations

  • Actor/recorder separation does not prevent the actor from omitting events before they reach the recorder: an actor can simply not call the logging API for an action it wants to suppress. Platform-native audit (CloudTrail, GCP Audit Logs) that captures every API call independently of application instrumentation is the primary residual-risk mitigation.
  • Hash-chained logs (CloudTrail log file integrity validation) detect tampering only if the digest chain root is published or held externally; an attacker with access to the S3 bucket before Object Lock is enabled can rewrite the chain.
  • GCP organization-level log sinks have a one-hop routing limit: you cannot chain sinks across multiple hops, which constrains multi-region log aggregation architectures.
  • The sidecar pattern assumes the container orchestrator (Kubernetes, ECS) enforces process-level isolation; a privileged container escape that gives the actor root on the host node defeats the sidecar identity boundary entirely.

Maturity tier reasoning

  • Tier 2 fits because every component is production-available: AWS CloudTrail organization trails and S3 Object Lock are Tier 1 within the AWS platform; GCP Cloud Logging aggregated sinks and HashiCorp Vault audit devices are production-stable; the agentic application of these primitives is documented composition.
  • What keeps this out of Tier 1 is the absence of a single standardised product that implements actor/recorder separation specifically for AI agent workloads end-to-end: every deployment assembles the pattern from cloud-native primitives, and the sidecar variant is entirely self-build.
  • The sidecar pattern has no off-the-shelf implementation and no industry-standard design specification; each deployment makes different choices about inter-process trust, crash behavior, and identity rotation.

Last verified against upstream docs: 2026-05-30.