secure_agent(). Use TrustRuntime directly when you need to control each enforcement point or integrate another framework.
Choose the Right Interface
The Controls Engine is a separate policy-as-data interface. Use Trust Runtime when you need identity-aware enforcement and framework integration in addition to content checks. Tool decisions become identity-bound when the runtime has an attested SPIFFE identity.
Install Trust Runtime
Install the core trust dependencies when you useTrustRuntime directly:
secure_agent() with LangGraph, Google ADK, or Strands:
trust and trust-adapters extras include SPIFFE identity support. If you only need SPIFFE identity with an otherwise minimal installation, install the standalone identity extra:
Protect an Agent With secure_agent()
Pass your agent object, its registered agent_id, and a constraint source to secure_agent(). The following examples use the local constraints dictionary from Configure Constraints. Start in warn mode while you validate the integration:
secure_agent() detects the framework from the agent object and installs the appropriate adapter. Change the mode to enforce when you are ready to block violations:
client and constraints, Trust Runtime creates a minimal local configuration with no content Guards and no tool permissions. Content scanning is skipped, and an enforced policy denies tools that are not explicitly permitted.
Integrate LangGraph
Pass either a LangGraphStateGraph or compiled graph. secure_agent() returns a SecureGraph that applies Trust Runtime around graph execution:
graph.compile() separately. The wrapper applies input and output Guards around graph execution. Tool access control is best-effort for LangGraph: the compiled graph must expose tool functions that the adapter can discover and wrap. Verify tool enforcement in your graph before relying on it.
Integrate Google ADK
Pass a Google ADKAgent. The adapter injects callbacks and returns the same Agent:
Integrate Strands
Pass a StrandsAgent. The adapter adds a trust hook provider and returns the same Agent:
secure_agent() raises TypeError. Use TrustRuntime directly or register a custom adapter when automatic framework integration is not available.
Configure Constraints
Trust Runtime resolves constraints in this order:- The
constraintsargument, supplied as anAgentConstraintsobject or dictionary. - The Console, when you provide a client and do not provide explicit constraints.
- A minimal local configuration with no content Guards or tool permissions.
The effective enforcement mode is the stronger of the local
mode and the mode in the resolved constraints. A local mode="warn" cannot downgrade Console-mandated or constraint-mandated enforce behavior.agent_id.
Use TrustRuntime Directly
Create a TrustRuntime when you need to place each check in your own execution flow:
Guard Inputs and Outputs
Run content through the configured Dome Guards before and after agent execution:flagged, whether the decision was enforced, a detection score, the optional guarded_response, execution time, and per-Guard trace information.
Use the asynchronous methods when your execution flow is asynchronous:
Check Tool Calls
Callcheck_tool_call() before executing a tool:
Guard Tool Responses
Run a string returned by a tool through the output Guards before sending it to the model:Wrap Tools
Usewrap_tool() or wrap_tools() to apply access checks and output Guards automatically:
enforce mode, a denied wrapped tool raises PermissionError. In warn mode, the runtime logs the denial and calls the tool. If a wrapped tool returns a string, Trust Runtime also applies the configured output Guards.
Understand Identity
Trust Runtime resolves identity through these paths:
The default SPIRE agent socket is
/run/spire/sockets/agent.sock. Set spire_socket when your SPIRE Workload API uses another location:
identity_unattested audit event. Whether an unattested Agent can call tools depends on the resolved unattested_tool_policy and enforcement mode.
Verify Tool Manifests
A tool manifest declares the tools an Agent expects to call. Each entry associates a tool name with its endpoint and expected SPIFFE identity. The manifest signature protects this inventory from undetected modification. Verify the manifest signature against a trusted public key before you pass the manifest toTrustRuntime. The runtime loads the manifest and uses it for endpoint attestation; attest() does not verify the manifest signature.
Pass a Path or a loaded ToolManifest to the runtime:
attest() connects to each declared endpoint, reads the SPIFFE ID from the peer certificate, and compares it with the expected identity. When the Agent has an X.509 SVID, the connection uses mTLS. Use attest_async() in an asynchronous application.
If no manifest is configured, attestation succeeds with an empty tool list. If a manifest is configured but the Agent is not attested, each tool verification fails because the runtime cannot establish an identity-bound verification path.
Framework adapters collect and expose the attestation result, but they do not stop startup when all_verified is False. If your deployment requires verified tool identities, inspect the result before the Agent accepts traffic.
The Dome repository contains the manifest model and client-side signing and verification code. Availability of the Console signing endpoints and packaged Manifest CLI still requires confirmation against the current Console release. A dedicated Manifest CLI reference is forthcoming.
Capture Audit Events
Trust Runtime emits anAuditEvent for security-relevant decisions. By default, it sends events to Python logging. Pass an audit_sink to route events to your telemetry pipeline:
event_type, configured agent_id, timestamp, and event-specific attributes. The runtime emits events for content Guard decisions, tool access checks, attestation results, identity or mTLS downgrade conditions, disabled Guards, and enforcement-mode downgrade attempts. Cryptographic identity fields are available only when the runtime has an attested identity.
See Observability for Dome tracing and metrics. Trust Runtime audit events complement those signals with identity and policy decisions.
Emit Enforcement Heartbeats
Setheartbeat_interval to emit an enforcement heartbeat on a schedule:
BeaconSigner when a downstream system must verify its origin. You can also manage the scheduler directly:
start_heartbeat() requires a positive interval and does nothing if a scheduler is already running. stop_heartbeat() is safe to call more than once.
Handle Failure Behavior
The following failures do not depend on the enforcement mode:
- A mode other than
warnorenforceraisesValueError. - An unsupported object passed to
secure_agent()raisesTypeError. - A non-positive heartbeat interval raises
ValueError. - An invalid manifest file fails while the runtime loads and validates it.
- Direct heartbeat emission propagates signer or audit-sink errors; scheduled emission logs the error and continues the scheduler.
attest() result prevents startup. Check all_verified before accepting traffic when tool identity is a deployment requirement.
Next Steps
Protection Overview
Compare Dome content Guardrails with the full Trust Runtime.
Configure Guardrails
Select and configure the content Guards used by Trust Runtime.
Detection Methods
Review the built-in Detectors available to Dome Guards.
Observability
Configure tracing, metrics, and logging for Dome.
Manifest CLI
Create, sign, and verify tool manifests from the command line.