A verifiable execution record provides the core audit artifact, capturing the complete step-by-step lineage including human-in-the-loop approvals and external API calls. The platform binds each step to actor identities and agent versions, creating a cryptographically tamper-evident chain. This enables replay to confirm the decision path. However, the record alone does not prove business rule correctness or external data integrity.
Human-in-the-loop checkpoints are managed by pausing durable execution at designated steps, awaiting human input while preserving full state. Once the reviewer responds, the platform records their identity, decision, and timestamp as a signed step within the verifiable execution record. This produces an immutable audit trail for auditors, proving human consultation at the required point. It does not validate the quality or business appropriateness of the human choice.
Catalyst allows operators to deploy within specific cloud regions, anchoring durable execution state, step records, and payloads to those locations with geo-fencing controls. Data at rest is encrypted with region-bound keys, and access is restricted to local endpoints, providing an immutable record of data locality. This helps satisfy data residency regulations. However, agent logic that calls external APIs may trigger data transfers outside the region; those calls are logged but not prevented.
Record retention is configurable, allowing organizations to set per-agent or global storage durations that match regulatory requirements. The platform retains immutable execution records, including step-by-step details, payloads, and signatures, and supports automatic archival or deletion after the configured period, providing auditor access within the retention window. This ensures compliance with data aging policies. However, when a retention policy is shortened, already-created records are not immediately deleted; a deferral prevents accidental data loss.
The platform offers role-based access controls that separate responsibilities: developers can author agent logic but not alter production records, operators manage infrastructure, and auditors receive read-only access to tamper-evident records, with payload visibility and access logs restricted per role. This ensures that no single role can create, deploy, and modify audit evidence, preventing unauthorized changes. However, effective separation also depends on proper identity provider integration and organizational policy enforcement, such as regular access reviews.
Present the platform’s verifiable execution record, which cryptographically chains each step and identity bindings—including human-in-the-loop checkpoints—to the agent’s logic and external inputs, proving adherence to the encoded policy. Auditors can replay the record to confirm no steps were skipped or reordered and that execution was deterministic. However, this demonstrates only that the agent followed the defined rules, not that those rules themselves satisfy the compliance policy.
Catalyst provides data lineage by logging all data source accesses during an agent execution, including identifiers and timestamps. This creates an auditable trail tracing how data moves through steps. For full coverage, ensure your agent routes all data access through traced interfaces. Lineage reflects observed interactions; it does not capture unauthorized data copying or transformations outside the platform’s view.
You can configure mandatory human-in-the-loop checkpoints that pause execution until approved. Catalyst logs each approval with timestamps and user identity, creating an auditable record of interventions. The enforcement relies on correct workflow definition; misconfigured steps might bypass the checkpoint, so audit configurations together with execution records to confirm proper setup.
Catalyst records the model endpoint used for each inference call. Auditors can cross-reference these endpoints against your approved provider list, establishing which models were invoked. This verification depends on the integrity of the recorded data. If the execution environment is compromised, records could be tampered with, necessitating runtime attestation for higher assurance.
Catalyst offers export APIs to transfer execution records to external archival systems, supporting long-term retention and integration with corporate governance tools. This enables auditors to access records beyond the platform’s retention period. Verify exports for completeness and integrity; the export mechanism does not inherently protect against data corruption during transfer or storage.
Catalyst logs guardrail checks, recording the rule and assessed content, providing evidence that safety measures were applied during agent runs. This log confirms guardrail execution but does not validate the guardrail’s effectiveness. Pair these logs with documented guardrail policies and periodic testing to assure auditors of comprehensive enforcement.
Prepare a package including verifiable execution records, human approval logs, data lineage traces, and guardrail invocation evidence. Attach the agent workflow definition and your compliance policy mapping. This package demonstrates the factual basis of decisions, but auditors must interpret it against your policies; the record proves what happened, not automatically that it was compliant.
Catalyst records human reviewer justifications as part of the verifiable execution step when configured with a human-in-the-loop checkpoint. The human input, including the reason text, is cryptographically bound to the step, ensuring it cannot be altered or omitted. This mechanism works only if the application explicitly captures and passes the justification to Catalyst’s API; it does not automatically record free-text commentary outside the defined step.
Yes, by combining Catalyst’s execution observability with external monitoring tools. Agent steps trigger events that can be streamed to alerting systems, which evaluate step attributes against predefined compliance policies. Alerts fire when a step’s parameters or outcomes breach thresholds. The accuracy depends on how well policies are defined; Catalyst itself does not pre-package compliance rule sets or real-time blocking.
Catalyst captures the timestamp and version identifiers of data sources accessed during a step, binding them into the verifiable record. An auditor can check these against source system logs to confirm recency. This only proves the agent requested the data at that moment; it does not guarantee the source itself was up-to-date or free from replication lag unless external freshness checks are integrated.
Catalyst’s execution records can be queried by business identifiers such as user ID attached to each run. You can export all executions that involved that ID, including inputs and outputs, in a verifiable format. This demonstrates what automated decisions were made and the data processed. The extraction covers only what the application logs as part of the execution; it cannot reconstruct decisions made outside the platform.
Catalyst’s deterministic replay of signed execution records allows an auditor to re-run the agent’s logic over multiple cases and compare outcomes. By replaying with the same rule configurations, one can validate that the same policies were evaluated. This replay is limited to steps that are fully deterministic; any non-deterministic steps may require the original seeded entropy to produce identical results.
Catalyst creates a verifiable step record for every model invocation, containing the provider URL and a cryptographic hash of the response. By checking these records against an approved vendor list, auditors confirm no unauthorized endpoints were used. Replaying the step with the same inputs validates the integrity of the evidence. However, this assumes the vendor itself does not redirect requests.
Catalyst captures every prompt exchanged with the model, including system and user inputs, in the cryptographically signed step record. By replaying the agent execution with these exact inputs, an auditor can identify prompt injection attempts. The raw record does not classify content as malicious; it supplies the data for external security analysis. Interpretation requires understanding the agent's expected behavior, which may not be fully encoded.
Catalyst structures execution records into a Merkle tree where each leaf is hashed and combined to form a root digest. Altering any record changes the root, making tampering evident. Periodic anchors of the root to an external witness provide a time-bound proof of existence. This cryptographic chain does not protect against physical destruction of the storage backing the data.
Catalyst records key rotation events with timestamps and links them to execution records through a key identifier embedded in each step signature. An auditor can reconstruct the signing key lifecycle and verify rotation compliance. This log does not prove a key was uncompromised before rotation; compromise may have preceded the rotation event. It provides evidence of the rotation operation, not prior key integrity.
Catalyst maintains a version history of agent workflow definitions, each identified by a content hash. Execution records reference this hash, allowing auditors to pin every decision to the exact workflow version that produced it. This evidence supports compliance assessment of changes over time, but does not automatically determine whether a version change broke policy.
Catalyst ensures non-repudiation by binding each human approval to a verifiable step that includes the approver's identity, authenticated timestamp, and optional digital signature. The approval event is cryptographically chained to the agent's execution record, making it impossible to alter without detection. Boundary: non-repudiation strength depends on the identity provider's authentication level and the security of the signing key managed by the operator.
Catalyst supports data minimization compliance by allowing operators to set granular retention policies that delete intermediate step payloads after execution completes. Execution metadata and the signed chain remain intact for auditing. This separation ensures that unnecessary personal data is not retained. Mechanism: catalogued data types have configurable time-to-live; once expired, the storage backend securely removes the data. Caveat: the burden of data classification rests on the operator; unstructured data is not automatically inspected for sensitive content.
Catalyst logs all outbound network calls as verifiable steps within the execution record, capturing destination, protocol, and purpose. Auditors can review this signed chain to confirm that only approved API endpoints were contacted. Mechanism: each external call is registered as a durable step with hashed payload references. Caveat: the log does not decode application-layer content; it is the operator's responsibility to ensure that encoded data or tunneling does not bypass endpoint checks.
Catalyst isolates concurrent executions through Dapr's virtual actors, assigning each run a unique, bounded state scope. The durable execution record per invocation proves that only that agent's logic modified its state. Mechanism: state operations are routed via the Agentic Durable Execution layer, which enforces per-invocation partition keys. Caveat: if agents share a common external database without proper partitioning, the platform cannot guarantee isolation beyond its own state management.
Catalyst's control plane emits signed attestations covering build provenance and runtime integrity, giving auditors a verifiable baseline. This leverages software supply chain provenance data and runtime monitoring to prove the engine has not been tampered with. Mechanism: An in-toto-style chain links build manifests, source code hashes, and deployment measurements. Caveat: The auditor must trust Diagrid's signing key and the cloud provider's hardware attestation; physical tampering is not detectable.
Catalyst records all modifications to guardrail rules, model-policy bindings, and approval workflows as verifiable events in a tamper-evident configuration ledger. Each entry includes the user, timestamp, and a diff of the change. Mechanism: the control plane emits signed audit entries that are append-only. Caveat: preventing unauthorized changes requires proper role assignments; the audit log alone cannot stop a rogue administrator who has obtained legitimate credentials.
