Agent Action Evidence Retention

When agents can take actions (calling tools, mutating data, triggering deployments, sending messages, etc.), you need an audit trail that answers:

• Which agent performed which action
• On behalf of whom (user, org, or service principal)
• What inputs and context were considered
• What outputs were produced
• Why the action was performed (reasoning / justification)
• How long the evidence is retained, and how integrity is preserved

This page describes a practical, audit-friendly approach for agent action evidence and a mock evidence model you can use as a starting point.

What Lamdis should capture for agent actions

At minimum, an action evidence record should include:

1) Identity and delegation (“who” and “on behalf of”)

• Actor: the entity that executed the action (an agent, an automation, a human)
• Principal: the entity the actor is acting for (a user, an org, a service principal)
• Authentication & session context: how the request was authorized (session id, token id, auth provider)

This distinction is crucial for audits: “Agent X performed action Y as User Z within Org O”.

2) Action details (“what happened”)

• Action type and target: e.g. connection.create, suite.run, secret.rotate
• Tool call / API call metadata: endpoint, method, tool name, arguments
• Outcome: success/failure, status code, error category

3) Decision record (“why it happened”)

• Reasoning summary: a human-readable rationale for the action
• Policy references: which policy/rule allowed the action (SOC2 control mapping, internal policy id)
• Approvals: whether a human approved (and who), or whether it was fully autonomous

Important: “reasoning” here means an auditable explanation, not necessarily a full chain-of-thought transcript.

4) Inputs/outputs and context (“what was considered”)

• User input: prompt/message (redacted if needed)
• System context: run id, suite/test id, environment id, correlation id
• Artifacts: files, prompts, retrieved docs, tool results
• Model metadata: model/provider/version, latency, token counts

5) Evidence integrity and retention (“can we trust it later”)

• Immutable storage option: WORM-capable object storage (e.g. S3 Object Lock)
• Tamper evidence: hashes for payload + artifacts; optional signatures
• Retention: default TTL by evidence class; legal hold
• Access controls: least privilege, separate audit readers, redaction

Retention guidance (practical defaults)

Suggested starting points (adjust to your compliance needs):

• High-risk actions (secrets, permissions, deployments): 1–7 years
• Routine actions (read-only tool calls): 90–180 days
• User-visible chat transcripts: configurable (often 30–365 days)
• Legal hold: indefinite until released

If you operate under SOC 2 Type II, ISO 27001, or regulated industries, long-lived retention for privileged actions is usually expected.

Minimal starter: Lamdis Evidence Model (Agent Action Evidence)

In Lamdis, represent this as an Evidence Model (Assurance → Evidence Models). Keep the first version small: you can always add fields later.

Minimal fields to start with

These are enough to answer “who did what, on behalf of whom, and why”:

Minimal validation rules (recommended)

• Require actor.type ∈ agent | user | service.
• Require action.status ∈ success | failure.
• Require decision.reasoningSummary to be non-empty (optionally enforce a small min length).

Minimal Evidence Model schema (JSON Schema)

If Lamdis stores your Evidence Model as JSON Schema, this is a lightweight starting point:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AgentActionEvidenceRecord",
  "type": "object",
  "required": ["schemaVersion", "evidenceId", "timestamp", "actor", "principal", "action", "decision"],
  "properties": {
    "schemaVersion": { "const": "1.0" },
    "evidenceId": { "type": "string" },
    "timestamp": { "type": "string", "format": "date-time" },
    "actor": {
      "type": "object",
      "required": ["type", "id"],
      "properties": {
        "type": { "enum": ["agent", "user", "service"] },
        "id": { "type": "string" },
        "name": { "type": "string" }
      }
    },
    "principal": {
      "type": "object",
      "required": ["orgId"],
      "properties": {
        "orgId": { "type": "string" },
        "userId": { "type": "string" }
      }
    },
    "action": {
      "type": "object",
      "required": ["type", "status"],
      "properties": {
        "type": { "type": "string" },
        "status": { "enum": ["success", "failure"] },
        "summary": { "type": "string" }
      }
    },
    "decision": {
      "type": "object",
      "required": ["reasoningSummary"],
      "properties": {
        "reasoningSummary": { "type": "string" },
        "policy": { "type": "array", "items": { "type": "string" } }
      }
    },
    "artifacts": {
      "type": "array",
      "items": { "type": "object", "properties": { "kind": { "type": "string" }, "uri": { "type": "string" }, "sha256": { "type": "string" } } }
    }
  }
}

Minimal example evidence item (what gets stored)

{
  "schemaVersion": "1.0",
  "evidenceId": "ev_01J0ZVJQ1E7Y8R2W4KZQ3D8S9N",
  "timestamp": "2026-02-01T19:02:11.442Z",
  "actor": { "type": "agent", "id": "agent_lamdis_helper", "name": "Lamdis Helper" },
  "principal": { "orgId": "org_123", "userId": "user_456" },
  "action": {
    "type": "connection.create",
    "status": "success",
    "summary": "Created a connection for a mock assistant so it can be used in test runs"
  },
  "decision": {
    "reasoningSummary": "User requested creating a runnable mock assistant. Creating a scoped connection enables test execution without granting broader privileges.",
    "policy": ["POL-AGENT-ACTIONS-001"]
  },
  "artifacts": [
    {
      "kind": "tool_input",
      "uri": "vault://evidence/ev_01J0ZVJQ1E7Y8R2W4KZQ3D8S9N/tool_input.json",
      "sha256": "b64:..."
    }
  ]
}

How this fits with Evidence Models and the Evidence Vault

• Use Evidence Models to enforce required fields for action evidence (e.g., privileged actions must include approvals).
• Store evidence records + artifacts in the Evidence Vault, ideally with immutable retention controls.

See also:

• Evidence Models
• Evidence Vault