Security architecture

Tracecat applies identity, policy, isolation, and audit controls outside the model so an agent cannot grant itself additional authority. This page describes the Tracecat Cloud security profile and hardened self-hosted deployments.

​

Security model

Tracecat treats prompts, retrieved context, model output, generated code, tool results, MCP servers, and client-supplied context as untrusted. The platform enforces authorization and execution controls at trusted boundaries that the model cannot modify. The security model addresses:

• Unauthorized access across organizations, workspaces, users, and service accounts.
• Agent goal hijacking, excessive agency, unsafe tool use, and approval bypass.
• Credential disclosure to models, prompts, or untrusted tool implementations.
• Unexpected code execution, resource exhaustion, and unintended network access.
• MCP and agent configuration changes that bypass review or approved policy.
• Actions that cannot be attributed to an identity, session, decision, or execution.

​

Outside the Tracecat boundary

You remain responsible for your identity-provider policies and the security of external model providers, APIs, MCP servers, Git repositories, and observability systems. Tracecat does not replace model evaluation, data-classification policy, prompt and content filtering, or adversarial testing. This model follows the risk families in the OWASP Top 10:2025, OWASP Top 10 for LLM Applications:2025, and OWASP Top 10 for Agentic Applications:2026. The mappings below identify the most relevant categories; they do not represent certification by OWASP. Mapping prefixes identify the source list: A is the OWASP Top 10 for software, LLM is the OWASP Top 10 for LLM applications, and ASI is the OWASP Top 10 for agentic applications.

​

Identity and platform boundaries

OWASP mappings: A01 Broken Access Control, A07 Authentication Failures, and ASI03 Identity and Privilege Abuse. Tracecat authenticates API and MCP requests before it resolves organization, workspace, and user context. SSO, RBAC roles, groups, and scoped service accounts restrict which resources and operations each identity can access. The managed multi-tenant profile applies tenant scope in both the application and database layers. PostgreSQL row-level policies provide a second boundary for organization-scoped and workspace-scoped data. Tracecat encrypts sensitive settings and stored credentials at rest and supports application-level encryption for Temporal payloads. Production traffic uses TLS in transit.

​

External secrets

OWASP mappings: A04 Cryptographic Failures, LLM02 Sensitive Information Disclosure, and ASI03 Identity and Privilege Abuse. You can keep workspace and integration credential values in AWS Secrets Manager. Tracecat stores the credential metadata and resolves the referenced value at execution time through the credential broker. For brokered API, remote HTTP MCP, and model calls, the model receives a typed interface rather than the downstream credential, and only the trusted proxy receives the resolved value. Credentials for a local stdio MCP process are an exception because that process shares the agent sandbox; treat them as accessible to agent-controlled code.

​

Agent and MCP control plane

​

Default-deny tool policy

OWASP mappings: A01 Broken Access Control, LLM06 Excessive Agency, and ASI02 Tool Misuse and Exploitation. Hosted agents apply the same deterministic policy boundary to Tracecat tools, remote MCP tools, and sandboxed stdio MCP tools. An agent can discover only tools that its identity, workspace, agent configuration, and tool policy allow. An explicit deny takes precedence over an allow. Tracecat rechecks brokered Tracecat and remote HTTP MCP invocations at the trusted proxy, so calling a hidden or stale remote tool directly does not bypass policy. Local stdio MCP is instead constrained to the tool inventory captured by the runtime and the shared sandbox boundary. A policy decision has one of three results:

• Allow: Execute the tool through the trusted proxy or isolated stdio process.
• Deny: Return a blocked result without resolving credentials or causing a side effect.
• Require approval: Pause before execution and create a durable approval request.

Tracecat bounds each hosted-agent run at the sandbox boundary with wall-time and resource limits. These controls contain loops and cascading failures without assuming a fixed number of model requests or tool calls.

​

Durable human approval

OWASP mappings: A01 Broken Access Control, A06 Insecure Design, LLM06 Excessive Agency, ASI02 Tool Misuse and Exploitation, and ASI09 Human-Agent Trust Exploitation. Tracecat uses Temporal durable execution to persist an agent at the approval boundary. The tool does not execute until an authorized approver accepts the request. The same approval decision remains attached to the run across retries, worker restarts, and time spent waiting. Tracecat does not authorize the tool until the recorded decision permits it. For authenticated UI and API decisions, Tracecat emits one audit event per tool with the approver, decision time, source, tool identifiers, accepted or rejected result, override indicator, and optional bounded, pattern-filtered denial reason.

​

External MCP connections

OAuth connections to Tracecat MCP inherit the authenticated user’s effective Tracecat permissions. Personal access tokens remain workspace-scoped. The MCP access page groups OAuth connections and personal access tokens by user and shows tool calls made through external MCP connections. Tracecat does not currently narrow an MCP profile below the user’s inherited scopes; fine-grained per-profile scope reduction is planned.

​

Trusted agent execution

OWASP mappings: A05 Injection, A06 Insecure Design, ASI05 Unexpected Code Execution, and ASI08 Cascading Failures. The secure execution profile runs hosted agent runtimes, agent-generated code, and local MCP processes inside nsjail boundaries. The agent sandbox exposes only the files, processes, and broker interfaces required for the run. General automation actions follow the network policy of their configured executor. These controls limit the blast radius of compromised model output or third-party code. They do not make untrusted code safe to run outside a supported sandbox profile.

​

Sandboxed MCP

OWASP mappings: A03 Software Supply Chain Failures, A08 Software or Data Integrity Failures, LLM03 Supply Chain, and ASI04 Agentic Supply Chain Vulnerabilities. Tracecat separates remote and local MCP execution:

• Remote MCP servers run outside the agent sandbox. The trusted Tracecat proxy resolves authentication, calls the approved server, and returns the result.
• stdio MCP servers run as child processes inside the agent sandbox and inherit its filesystem, network, time, resource, and identity boundaries.

Tracecat captures the approved MCP server and tool inventory for the run, and normal SDK-dispatched calls are limited to that inventory. Because agent-controlled code and stdio MCP share one sandbox, local MCP is not a separate tool-policy isolation boundary against code that invokes the local executable directly; use remote HTTP MCP when calls must be rechecked at the trusted proxy.

​

Trusted API and model gateways

For brokered API, remote HTTP MCP, and model calls, the secure preset-agent path keeps secret values out of model context and the agent sandbox. Tracecat evaluates secret references only after the model produces a permitted tool or model request, then its built-in API and MCP proxy adds the downstream API, OAuth, MCP, or model credential outside the sandbox. The agent receives the typed result, not the credential. You can use Tracecat’s managed model gateway or configure an OpenAI-compatible provider and BYO model. The customer provider can route requests through an LLM proxy without changing the agent’s tool boundary. See Secrets and variables for the secure preset-agent path and its limitations.

​

Auditability and change control

OWASP mappings: A09 Security Logging and Alerting Failures, LLM10 Unbounded Consumption, and ASI08 Cascading Failures. Tracecat separates user-centric platform audit events from full hosted-agent runtime telemetry. The scoped OTEL relay accepts telemetry from the sandbox without exposing the destination credential to the agent runtime. You control which backend receives it and how that system filters, retains, and alerts on the data. Native model-runtime tool telemetry captures the initial tool decision, which can be an interruption while Tracecat waits for approval. Tracecat emits a complementary approval-decision event for the later human accept or reject result. Platform approval audit events cover authenticated Tracecat UI and API users and exclude raw tool arguments, override values, credentials, prompts, and outputs. Slack-originated approval actor events are not included yet, and audit webhook delivery remains best-effort so a slow or unavailable collector cannot delay or roll back a decision.

​

Workspace Git sync

Use Workspace Git sync to move agent and automation configuration through your existing Git change-management process. Tracecat supports customer-owned GitHub and GitLab repositories so you can review changes, apply branch protection, and promote approved configuration from staging to production. Git history complements platform audit logs by recording the reviewed configuration that entered each environment. Runtime authorization still comes from Tracecat RBAC and policy, not from repository access alone.

​

Deployment profiles

See Self-hosted security for backend selection and Kubernetes for the hardened deployment requirements.

​

Further hardening

Tracecat provides enforcement at its control-plane and execution boundaries. Add independent controls when your risk model requires defense in depth:

• Route model traffic through your LLM proxy to apply prompt firewalls, content policy, PII or DLP filtering, model allowlists, and provider-level budgets.
• Place your MCP proxy in front of Tracecat MCP or between Tracecat and a downstream MCP server for an additional allow, deny, inspection, or consent layer.
• Export agent OTEL data and platform audit events to your observability or SIEM platform, then define customer-specific detections, retention, and incident response.
• Red-team agents before production and after changes to prompts, models, skills, tools, or MCP servers. Test goal hijacking, tool misuse, poisoned context, approval manipulation, and cross-tool data exposure.

Review the MCP security best practices and the NIST Generative AI Profile when you define these controls.

​

Related pages

• See AI agent to configure tools, MCP servers, approvals, request bounds, and network access.
• See Secrets and variables to keep credential values out of preset-agent model context.
• See MCP servers to connect remote and sandboxed stdio servers.
• See Custom LLM providers to route agents through a customer model or LLM gateway.
• See Organization audit logs to stream platform audit events to your log collector.
• See Self-hosted security to select and harden an execution backend.