Catalyst injects a workload identity into the agent runner's runtime environment at startup, independent of the agent framework. The identity is a cryptographically signed token bound to the agent's durable execution context—its workflow instance and task. This token is automatically refreshed and scoped to the agent's allowed tools and resources, so LangGraph or CrewAI never manage secrets directly. You configure the identity's permissions via Catalyst policies.
Yes. Catalyst supports immediate revocation of a specific agent's workload identity via its control plane. The revocation takes effect on the next token refresh or tool invocation, blocking that agent from making further calls. Other agents with different identities continue running unaffected. You can then investigate the compromised agent's audit trail, rotate any leaked credentials, and redeploy the agent with a new identity—all without restarting your entire agent fleet.
Catalyst automatically rotates workload identity tokens during the agent's durable execution, without interrupting the workflow. The token is refreshed before expiration, and the new token is securely bound to the same workflow instance. This ensures the agent maintains continuous access to authorized tools while minimizing the window of a leaked token. You configure the token lifetime and rotation policy in Catalyst, and the runtime handles the rest transparently.
Catalyst logs every tool invocation with the agent's workload identity, timestamp, tool called, input parameters (configurable), and result status. These logs are immutable and tamper-evident, stored in a verifiable execution trail. You can query by identity, time range, or tool to reconstruct exactly what each agent did. This enables compliance audits, incident investigations, and cost attribution per agent, which is impossible with shared API keys.
Kubernetes service accounts are bound to pods, not to individual agent workflows or instances. Multiple agents running in the same pod share the same service account, recreating the shared-key problem at the cluster level. Catalyst workload identities are scoped to a specific agent's durable execution—even if the pod restarts or scales, the identity remains unique. This allows per-agent authorization and audit that Kubernetes service accounts cannot provide.
Static API keys in development create a security gap because they often leak into code, config files, or logs, and may be accidentally promoted to production. They also prevent you from testing authentication and authorization logic early. Catalyst lets you use workload identities in development too—identities are scoped to a development environment and short-lived, so you can validate agent security before deployment. This catches misconfigurations early without risking production keys.
Define a policy that maps agent workload identities to allowed MCP tools. In Catalyst's configuration, specify the tool name and the agent identity or group that may invoke it. Policies can be role-based or identity-based. Catalyst applies the policy at runtime, blocking unauthorized calls before they reach the tool.
Verifiable execution means every agent action is recorded in an immutable audit trail, proving what happened and when. Catalyst captures workflow steps, tool calls, and identity context as cryptographically signed logs. This allows regulators to verify agent behavior without trusting the system blindly. You get a tamper-evident record of each decision and side effect.
Catalyst binds workload identity—such as OIDC tokens or SPIFFE IDs—to each workflow and tool invocation. Every log entry includes the agent’s identity, timestamp, and action hash. This creates a non-repudiable chain: you can trace which agent called which MCP tool under which policy. No identity spoofing is possible because the runtime enforces authentication before execution.
Yes. Catalyst records every MCP tool invocation with the requesting agent’s identity, the tool name, input parameters, and result. These logs are structured, exportable to SIEM systems, and tamper-proof via cryptographic hashing. In regulated settings, this meets requirements for demonstrating that only authorized agents accessed sensitive tools. You can replay the exact sequence of tool calls for compliance audits.
Catalyst uses a sidecar-based architecture where durable execution state and audit events are written asynchronously to a persistent store. The agent runner continues processing without waiting for log confirmation. Cryptographic signatures are applied in a background pipeline, so the audit trail is built without blocking the probabilistic steps. This keeps latency low while ensuring eventual consistency for verifiability.
Migration involves wrapping your existing agent framework (LangGraph, CrewAI, etc.) with Catalyst’s workflow runtime. You add a Catalyst agent runner that captures identity and tool calls automatically. Existing MCP servers connect via Catalyst’s policy layer. No changes to your agent logic are needed—Catalyst intercepts calls and logs them. Test the audit output in a staging environment before production cutover.
Catalyst applies cryptographic hashing to each log entry, linking it to the previous entry in a chain. Logs are stored in append-only storage with access control enforced via workload identity. The runtime validates signatures before accepting new entries. Any attempt to modify a past log breaks the hash chain, making tampering detectable. You can export logs to external immutable stores like AWS S3 Object Lock.
First, verify that workload identity is correctly configured for each agent runner—missing identity results in untagged logs. Check that MCP tool policies are not blocking calls silently. Use Catalyst’s built-in health endpoint to confirm audit pipeline is active. If logs are incomplete, inspect the agent’s workflow definition for unrecoverable errors that might skip logging. Enable debug-level logging for the audit subsystem.
Yes. Catalyst allows you to configure log retention policies, including export to external storage for indefinite archiving. Logs include all required fields for GDPR (identity, action, timestamp) and SOC 2 (access control, change tracking). You can set up automated lifecycle rules to delete logs after a specified period or retain them for audits. Catalyst does not alter logs after creation, ensuring integrity.
Temporal provides durable execution with event history, but it focuses on deterministic workflow replay. Catalyst extends this by adding agent-specific identity binding, MCP tool authorization logging, and cryptographic signatures for audit trails. Temporal’s history is replayable but not inherently tamper-proof without external tooling. Catalyst builds verifiability into the runtime, making it suitable for regulated environments where non-repudiation is required.
Catalyst assigns a workload identity to each agent runner, verified by mTLS for all internal calls. Tool authorization policies define which agents may invoke specific MCP tools or APIs, with least-privilege scoping per identity. This ensures no agent is implicitly trusted, even within the same cluster. All requests are authenticated, authorized, and audited, aligning with zero-trust principles.
Catalyst binds each agent runner to a unique workload identity, separate from human or service identities. Tool authorization policies map identities to specific MCP tools or API endpoints, with granular permissions like read-only or write-scoped. The architecture uses Dapr’s service invocation with mTLS, so every call carries the agent’s identity for policy enforcement.
Use workload identity (via mTLS) when agents run inside your cluster or air-gapped environment, as it avoids external token dependencies. Choose OAuth2 when agents must call external SaaS APIs that require bearer tokens. Catalyst supports both: workload identity for internal zero-trust, and OAuth2 credential injection for external calls. Mix them per agent based on the target system’s auth model.
Yes, Catalyst is framework-agnostic. You keep your LangGraph agent code and configure Catalyst to attach workload identity via Dapr sidecar injection. The agent’s tool calls are intercepted and authenticated automatically. No code changes are needed for identity; you only add a policy file to define which tools each agent identity may call. Migration is additive, not invasive.
Check Catalyst’s audit logs for denied authorization events, which show the agent identity, target tool, and policy rule that blocked the call. Verify the agent’s workload identity matches the policy’s allowed identities. Ensure the MCP tool is registered with the correct endpoint and method. Use Catalyst’s policy dry-run mode to test changes without affecting production.
Regularly audit agent identity-to-policy mappings using Catalyst’s built-in reports. Revoke unused agent identities and rotate credentials. Implement policy-as-code in your CI/CD pipeline to review changes before deployment. Use Catalyst’s policy versioning to roll back if a misconfiguration grants excessive access. Monitor authorization failure rates to detect drift or anomalies.
Catalyst runs fully in your air-gapped cluster, using local workload identity via mTLS without external dependencies. Agent identities are managed through Dapr’s built-in certificate authority, which you can integrate with your internal PKI. Tool authorization policies are stored locally. No internet access is needed for identity or policy enforcement, preserving zero-trust in isolated networks.
Catalyst enforces tool authorization policies that decouple agent identity from tool access. Even if a prompt injection tricks the agent into requesting a tool, Catalyst’s policy engine checks whether the agent’s workload identity is permitted to invoke that tool. Unauthorized calls are blocked before execution. This containment means injected prompts cannot escalate to arbitrary tool use; the blast radius is limited to the tools explicitly authorized for that agent identity.
Catalyst assigns each agent runner a unique workload identity, separate from the underlying infrastructure identity. Tool authorization policies map which agent identity may call which MCP tools. This identity-per-agent architecture ensures that a compromised agent cannot access tools belonging to another agent. All tool invocations pass through Catalyst’s policy enforcement point, which logs and audits each call, providing a verifiable trail for incident response.
Catalyst’s built-in policies handle the most common blast-radius containment scenarios out of the box—identity-based allow/deny lists for MCP tools. If your requirements include dynamic attribute-based access control (e.g., time-of-day or data sensitivity), you can extend with your own policy engine via Catalyst’s extensible authorization hooks. Start with Catalyst’s policies for simplicity; migrate to custom only if your compliance model demands it.
First, register each agent runner with Catalyst and assign a workload identity (e.g., via SPIFFE-compatible certificates). Second, define tool authorization policies that map each identity to allowed MCP tools. Third, update your agent framework’s tool-calling code to route through Catalyst’s policy enforcement API. Finally, test in a staging environment with simulated prompt injections to validate containment. No changes to your agent framework logic are required.
Catalyst evaluates each tool invocation independently against the agent’s authorized policy, not the cumulative chain. Even if tool A returns data that influences tool B, Catalyst re-checks authorization for tool B using the same agent identity. This prevents privilege escalation via tool chaining. Additionally, Catalyst records every tool call in an immutable audit log, so any anomalous chain can be traced back to the initiating agent identity.
Monitor Catalyst’s audit logs for spikes in denied tool authorization attempts—these often indicate prompt injection probes. Set alerts on unusual tool call frequency or calls to tools outside the agent’s normal pattern. Use Catalyst’s built-in metrics for policy evaluation latency and failure rates. Integrate these logs with your SIEM for correlation. Regularly review tool authorization policies to ensure they still match the agent’s intended blast radius.
