Local execution records can support SOC 2 CC7 evidence

Local tamper-evident execution records can support SOC 2 CC7 evidence, but they cannot carry CC7.1 or CC7.2 by themselves. They can show which local agent process started a session, which credentialed calls it attempted, how those calls ended, and whether the stored history changed. They do not show that every in-scope system received vulnerability monitoring or that a person investigated anomalies on schedule.

That boundary matters. I have seen teams hand an auditor a beautifully signed log export and call it their monitoring control. The export proved that events existed. It did not prove coverage, detection logic, review, escalation, or remediation. Treat the local record as one evidence source in a control system, and it becomes useful. Treat it as the control, and the gaps surface during sampling.

The practical test is simple: connect every claim to a field, a procedure, an owner, and corroborating evidence. If one of those is missing, write down the limitation before the auditor does.

CC7.1 and CC7.2 ask different questions

CC7.1 asks whether the entity uses detection and monitoring procedures to find configuration changes that introduce vulnerabilities and exposure to newly discovered vulnerabilities. CC7.2 asks whether the entity monitors system components and their operation for anomalies associated with malicious acts, natural disasters, or errors, then analyzes those anomalies to decide whether they are security events. A record of an agent's API or SSH action can contribute to both criteria, but in different ways.

For CC7.1, an execution record is usually change evidence. It may show that an agent altered a firewall rule, deployed a package, changed an identity setting, or ran a command against a host. That evidence helps a reviewer connect a detected configuration drift or new exposure to the process that caused it. The record does not detect a newly published vulnerability unless some separate scanner, advisory feed, inventory service, or review procedure compares deployed components with new vulnerability information.

For CC7.2, the same record is operating telemetry. A denied call, an unexpected destination, repeated authentication failure, unusual command, or action outside an approved session may be an anomaly input. Yet a stored event is not the same thing as monitoring. The organization still needs a defined way to select events, recognize suspicious patterns, route them to a reviewer, and document the decision.

This distinction prevents a common mapping error: equating logging with detection. A log source records observations. A detection control applies logic or human judgment to those observations. An auditor will often test both the design and the operation, so evidence that proves only collection answers half the question.

The AICPA Trust Services Criteria provide points of focus rather than a universal tool list. That gives a company room to design controls that fit its risks, but it also removes the comfort of a magic retention period or required product category. Your system description, risk assessment, control wording, and actual procedure determine whether local execution data is relevant.

A narrow, defensible control statement might say: "Security reviews agent-mediated production actions each business day for denied calls, failed calls, new destinations, and privileged SSH commands; the reviewer records disposition and escalates suspected events under the incident procedure." That statement identifies the population, signals, cadence, owner, and follow-up. "We keep tamper-evident logs" identifies only a storage property.

Session identity must describe the process, not imply a person

A useful session record identifies the agent process strongly enough to distinguish one run from another. At minimum, capture a unique session identifier, process start and end times, executable path, code-signing identity or binary digest, parent process, host identifier, local account, authorization decision, authorizer, and revocation state. Preserve the method used to obtain each field because a value reported by the agent deserves less trust than a value observed by the execution gateway or operating system.

Do not silently turn process identity into human identity. A code-signing authority can tell you who signed a binary. A local account can tell you which operating-system context launched it. Neither proves which employee wrote the prompt, approved every action, or intended a particular command. If your control needs human attribution, join the session to identity-provider login records, device management data, approval records, ticket ownership, or a controlled workstation assignment.

The same caution applies to parent-child relationships. A shell may launch an agent, which launches a helper, which requests an SSH action. Record the observed chain, but define which process is the control subject. Otherwise, one team will group by the top-level agent while another groups by the helper, and the sample population will change halfway through the audit.

A compact session object can make the evidence contract explicit:

{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}

The ellipsis above marks an abbreviated example, not an acceptable stored identifier. Production evidence needs the complete value and a documented uniqueness rule. It also needs clock synchronization evidence. If endpoint, gateway, identity, and ticket timestamps drift, an auditor cannot reliably reconstruct sequence even when every source is internally consistent.

For Sallyport, the Sessions journal records agent runs, while first-call approval leads with the process's code-signing authority and lasts until that process exits. That is good local session evidence, but teams still need external records when their control claims a named employee, managed device, approved change, or corporate login.

Call outcomes need enough context to support a decision

An individual-call record should answer what the process tried, where it tried it, which credential reference or key class the gateway used, whether approval was required, what decision occurred, whether execution started, and how it ended. Capture timestamps and duration, channel, normalized destination, action type, result class, error class, and a stable correlation identifier. Store enough command or request detail to investigate without copying secrets or sensitive response bodies into the audit trail.

Outcome vocabulary needs discipline. "Denied" should mean a control stopped execution before the external action. "Failed" should mean execution began but returned an error, timed out, or lost transport. "Succeeded" should mean the remote interface reported success under a documented rule. "Unknown" should cover the awkward case where the client lost confirmation after sending the action. Collapsing denied and failed calls into one error bucket destroys evidence about whether the control operated.

HTTP status alone rarely tells the whole story. A 200 response can contain an application error. A 202 may mean that work was only queued. An SSH exit code of zero shows that the remote shell command reported success, not that the intended system state changed. Define result normalization per action type, and preserve the raw status or exit code beside the normalized result.

A practical call record can look like this:

{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}

Avoid recording a bearer token, private key, full authorization header, or raw response merely because it makes the evidence feel complete. An audit log that leaks secrets creates a separate control failure. Use a stable credential reference and record the injection method, while keeping secret material outside the agent and outside exported evidence.

For CC7.1, reviewers can correlate change-capable calls with configuration drift, deployment records, and vulnerability findings. For CC7.2, they can select denied, failed, unknown, unusual-destination, or high-risk actions for analysis. The call record supports those procedures only if the organization can enumerate the complete population. A screenshot of five interesting events proves that five events existed, not that reviewers considered all relevant events.

Integrity checks prove history consistency, not event truth

A hash chain can detect deletion, insertion, reordering, or modification after records enter the chain, provided the verifier starts from a trusted format and anchor. It does not prove that the source captured every action, that each field was accurate when written, or that an attacker never bypassed the logger. This is the sharpest distinction in tamper-evident logging: record integrity is not collection completeness.

Write-blind encrypted storage reduces the chance that a reader or compromised analysis path can rewrite prior entries. Encryption protects confidentiality. Chaining protects detectable continuity. Hardware-backed keys may strengthen access control. These mechanisms answer different audit questions, so document them separately rather than calling the whole design "immutable."

An integrity procedure needs repeatable inputs and retained results. With Sallyport, a reviewer can verify the encrypted chain offline without a key:

$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid

The exact output must come from the installed release; the shape above defines what the evidence packet should retain: command, tool version, file identifier or digest, record count, time bounds, result, execution time, and operator. If the real command emits different labels, preserve its output rather than rewriting it to match this example.

Run a negative test before relying on the procedure. Copy a nonproduction export, alter or remove one record using a test fixture supported by your engineering team, then confirm that verification fails. Keep the test method, expected failure, actual output, tool version, and reviewer sign-off. A successful verification alone shows that one file passed; a controlled negative test shows that the checker detects the alteration you claim it detects.

Also reconcile boundaries. Compare the last record count and chain anchor from one export with the first expected state of the next. Investigate gaps, resets, reinstallations, clock jumps, and host replacements. If local administrators can erase the entire log and its anchor, the chain may faithfully verify only the replacement history. Ship anchors, digests, or signed export receipts to a separately controlled location often enough to match the risk.

NIST Special Publication 800-92 recommends protecting archived-log integrity and verifying transferred logs, commonly by comparing message digests. That advice still holds, but a digest or chain does not replace source-coverage monitoring. Use it to make transfer and retention failures visible, then test whether all in-scope sources actually report.

Retention starts with the control period and investigation need

SOC 2 does not assign one universal number of days to CC7.1 or CC7.2 evidence. Set retention from the audit period, contractual and legal duties, incident investigation needs, detection delay, storage sensitivity, and the time needed to produce a sample. The policy should name the retained event classes, location, owner, access restrictions, disposal method, and exception process.

For a Type 2 examination, the auditor tests operation over a period. If the team keeps only the most recent slice of local history, it may be unable to support early-period samples or show continuity. Keep evidence long enough to cover the full examination period plus preparation, fieldwork, and a reasonable buffer for follow-up. Have counsel or the compliance owner resolve any longer legal or contractual obligations rather than copying a duration from another company's report.

Local-only retention carries a predictable failure mode. A laptop is replaced in April, its journal disappears, and the October audit sample includes February. The team then has a perfect chain for the replacement device and no evidence for the selected date. Export records and verification anchors to organization-controlled storage under a defined schedule, and retain proof that scheduled exports ran.

Test retrieval, not just settings. Pick an early-period date, locate the session population, retrieve the call records, verify integrity, and connect one event to its review disposition. Record elapsed time and failures. A retention configuration screenshot shows design. Successful retrieval from an old period shows operation.

Privacy and security still apply. Commands, destinations, local account names, and error bodies may contain personal data or sensitive infrastructure details. Restrict evidence access, redact exported copies under a documented rule, and retain an unredacted source only where authorized. Never let redaction alter record ordering or invalidate the verification path without preserving an independently verifiable original.

Review cadence must match the signal and leave proof

A review control works when a named role examines a defined population at a stated cadence, applies written decision criteria, and records disposition. "Logs are reviewed regularly" cannot be sampled with confidence because nobody knows what regular means or which logs count. Daily business-day review may fit agent actions against production. Per-call approval may fit a small set of powerful keys. Weekly trend review may fit lower-risk development destinations. The risk assessment should explain the choice.

Separate preventive approval from detective review. Approval decides whether an action may proceed. Review asks whether allowed, denied, failed, and bypassed actions indicate an anomaly or control problem. If a person approves a risky call, that does not prove anyone later checked the outcome, correlated related calls, or recognized a compromised session.

Define review selectors in plain language before choosing tooling. A workable procedure might select all calls with result equal to failed or unknown, all denied approvals, every new destination, all uses of designated production credentials, sessions started by an unrecognized signing authority, and any integrity failure. The reviewer marks each item expected, operational issue, policy deviation, or suspected security event. Suspected events receive an incident identifier and escalation timestamp.

Keep zero-result evidence. On a quiet day, the saved query, covered time window, execution timestamp, reviewer identity, and zero count prove that the procedure ran. A month containing only tickets for positive findings creates doubt about the days with no tickets. Auditors sample the control performance, not only the exciting cases.

Review evidence should include:

• The population query or export criteria and its version.
• The covered start and end times, timezone, and record count.
• Reviewer identity, completion time, and any late-review explanation.
• Each selected anomaly, disposition, and supporting rationale.
• Incident, change, or problem ticket references when escalation occurs.

Do not let the event producer be the only reviewer of its own history. Small teams may lack full separation, but they can use compensating review by another responsible person, periodic management inspection, and separately controlled exports. Describe the actual arrangement. An invented segregation claim is worse than an honest limitation with a sensible compensating control.

Cadence also applies to control health. At a defined interval, confirm that expected hosts produced records, exports completed, clocks remained synchronized, integrity checks passed, detection selectors still match the schema, and reviewers closed their queues. Schema changes can silently break a query that looks healthy. Include a known test event or a monitored count boundary so the team notices when the pipeline stops selecting anything.

CC7.2 requires analysis to determine whether anomalies are security events. Closing a ticket as "false positive" without a reason does not show analysis. The record should state what happened, why it did or did not threaten objectives, what evidence supported the decision, who made it, and whether follow-up changed a detector or procedure.

Build the auditor packet around claims and samples

An auditor usually asks for design evidence first, then operating evidence from selected dates or events. Package local execution records so each artifact answers a stated control claim. Do not lead with a raw archive and expect the auditor to discover your control inside it.

Use this mapping as a working evidence index:

For each control, maintain a one-page evidence definition with the control wording, owner, frequency, system population, event population, procedure, expected artifacts, storage location, and exception handling. Add a field dictionary for every exported column. Auditors should not have to guess whether actor means employee, local account, process, or signing authority.

Prepare two sample paths. The first starts with a randomly selected date and proves the complete review ran on time. The second starts with a selected high-risk call and traces backward to session authorization and forward to remote outcome, review disposition, and any change or incident ticket. These paths test different claims. A date sample tests recurring operation, while an event sample tests traceability.

Reconcile totals at every handoff. The session journal count should agree with the session export under the documented filters. Call counts should agree before and after transfer. Review-input counts should reconcile to selected, excluded, and unresolved items. Explain legitimate differences such as test environments, approved exclusions, duplicate retries, or records outside the control window.

A Type 1 report evaluates control design at a point in time. A Type 2 report also evaluates whether controls operated over the stated period. A current screenshot, fresh integrity check, or recently written procedure may help Type 1 design evidence but cannot recreate months of missing Type 2 operation. If the history does not exist, disclose the gap and reset the readiness timeline instead of manufacturing retrospective sign-offs.

Before fieldwork, ask the auditor how they want encrypted or sensitive evidence delivered, which attributes they expect in samples, and whether they will select dates, sessions, calls, or alerts. That conversation changes packaging, not the control. The control must already operate consistently before the sample arrives.

Collect coverage and response evidence elsewhere

Local execution records cover only actions that pass through the local execution path. They do not prove that all production changes use that path. Administrators may use cloud consoles, direct SSH, CI/CD credentials, provider support channels, emergency accounts, scheduled jobs, or another workstation. Build an inventory of change and access paths, then either bring them into the control or collect their logs separately.

CC7.1 needs evidence beyond execution history:

• Current asset and software inventory tied to the audit scope.
• Configuration standards and approved baseline versions.
• Vulnerability scan configuration, coverage, results, and scan health.
• A process for newly disclosed vulnerabilities and affected-component matching.
• Remediation tickets, risk acceptances, deadlines, retests, and exceptions.

An agent call that installs package version X is useful change evidence. It does not tell you that version X became vulnerable three weeks later. The vulnerability management system, advisory intake, software inventory, and remediation record must supply that story.

CC7.2 also needs broader sources. Collect endpoint, identity, network, cloud control-plane, application, database, and availability telemetry according to the scoped risks. Retain detector definitions, enabled-source inventories, alert-routing tests, on-call or reviewer assignments, alert histories, dispositions, incident records, and post-incident actions. Natural-disaster and operational-error coverage may require availability alarms and continuity procedures that an action gateway never sees.

Prove completeness with reconciliation. Compare managed devices with devices exporting local records. Compare production credentials with credentials available through the gateway. Compare cloud changes with gateway calls and approved automation. Investigate unmatched records in both directions: a cloud change without a local call may show bypass, while a successful local call without the expected remote change may show bad result normalization or rollback.

Collect governance evidence too. The risk assessment should explain why agent actions matter to CC7.1 and CC7.2. Policies should assign log, vulnerability, monitoring, review, incident, and retention responsibilities. Training or procedure acknowledgment should cover the people who approve and review actions. Access reviews should show who can read, export, administer, or delete evidence and who can change detection logic.

NIST Special Publication 800-92 treats log management as generation, transmission, storage, analysis, and disposal. That lifecycle is a useful challenge to local-only thinking. If your evidence design addresses generation and storage but skips transmission, analysis, and disposal, it remains unfinished even when the cryptography is sound.

Keep an explicit evidence-gap register with the uncovered system, missing period, affected control, risk, interim procedure, owner, and target date. Auditors do not expect a small execution log to observe an entire company. They do expect management to know its scope and avoid claims the evidence cannot support.

Use local records as a narrow, testable control component

Local tamper-evident records are worth using when the control statement matches what they observe. They can provide high-resolution session and call evidence, preserve denied attempts that remote systems never receive, and make later modification detectable. They are especially useful for tracing AI agent activity because remote APIs often see only a shared service identity and lose the local process context.

They become weak evidence when teams overstate identity, ignore bypass paths, retain data only on replaceable endpoints, or confuse a valid chain with complete monitoring. The cure is not another cryptographic adjective. It is a smaller claim, a documented population, recurring review, separately retained verification results, and joins to authoritative systems.

Before relying on the records, run one end-to-end control test with a seeded event. Start an identifiable test session, attempt an approved action and a denied action, confirm both outcomes, export the period, verify the chain, run the review selector, record the disposition, and reconcile the remote system's corresponding event. Then repeat the retrieval against an older period. Every break in that sequence is a real evidence gap.

Give the auditor the chain result, but also give them the source inventory, selector, review proof, exception trail, and external corroboration. That packet supports a defensible CC7.1 or CC7.2 control. The chain alone supports only the modest claim that the supplied local history still has the structure the verifier expected.