Draft, test, publish
Edits stay in a draft until an authorized administrator publishes an immutable revision. Test samples without dispatching anything.
Security & Governance
Govern AI agents at the action layer.
Scope identities, credentials, tools, and operations for each agent. Require human review for supported consequential actions. Preserve evidence that helps authorized reviewers reconstruct what happened.
Authority scoped by identity and operation
Action-specific human review
Evidence with explicit coverage limits
Demo / 57 seconds
Watch your security tool halt an agent.
A Splunk alert requests a hold on one agent through a scoped API. The record shows the real enforcement result, and only a named person can release it.
Read the transcript
Your security tools just flagged an AI agent. It’s already on hold. With Decision Terrain, the tools you trust can stop an agent.
Your agents work in your systems, under your rules. When one tries something it shouldn’t, it’s blocked and logged. That event reaches your SIEM like any other security signal, and your alert fires. It requests a halt on that one agent, through a scoped API. New work stops.
The record shows who asked, when, which agent, and the real enforcement result, including what’s still unresolved. Only a named person can release it, with a reason. The halt and the release are both on the record.
Per agent. Human release. Recorded. That’s governed autonomy. That’s Decision Terrain.
On screen: “Does not reverse completed actions.” Fictional demo data, local development capture.
01 / Control model
Follow authority from the initiator to the evidence.
Credentials, grants, operation policies, and covered security rules enforce their own boundaries. Charters and instructions guide the work; they are not hard permissions.
- 01
Initiator
The authorized person or system that starts the work.
- 02
Agent
The assigned agent, with its owner, Team placement, and collaborators.
- 03
Tool
The configured API, email, browser, or other available capability.
- 04
Permission
Grants, credential scope, destinations, and operation policy define available authority.
- 05
Approval
Supported, configured operations may pause for an authorized human decision.
- 06
Execution
The autonomous or approved operation runs through its configured path and provider.
- 07
Evidence
Enabled records can help reviewers examine the action, decision, and outcome.
Details and limits
Assign a useful responsibility, then configure the authority needed to carry it out.
Approval boundary. Human approval applies only to supported operations configured for review. It does not govern every browser action, integration, or third-party write.
Evidence boundary. Available evidence depends on enabled capture, reviewer permissions, retention policy, and external-provider records.
Illustrative exact-call example. An agent proposes changing one status record through a governed OpenAPI operation. A configured approver who can manage that agent reviews the operation, arguments, and context. Approval covers that call; changed arguments, credentials, configuration, reviewer authority, or expiry can invalidate it. Inspect the recorded result and check the target system before retrying an uncertain write. This is an implementation pattern, not a demonstrated successful write. See how the operation is configured.
02 / Identity, credentials, and access
Establish who can act—and what the agent can reach.
Organization roles, Team access, agent ownership, and explicit grants define the working boundary. Linking agents does not merge their access.
- Roles that separate identity, security, agent management, audit, and billing
- SAML 2.0 or OpenID Connect SSO and SCIM, where enabled for the deployment
- Scoped credentials, destination restrictions, and per-agent tool denial
Details and limits
Underlying provider permissions remain part of that boundary.
Separate use from administration. Organization roles distinguish identity, security, agent management, audit, and billing responsibilities. Team roles and agent collaborators narrow access to shared work. Organization-private agents remain subject to company policy and authorized administration without automatically sharing their work with ordinary coworkers.
Manage sign-in, sessions, and offboarding. Deployment-enabled SAML 2.0 or OpenID Connect SSO requires domain verification, provider testing, and activation. SCIM synchronizes Organization membership and supported group mappings; deactivation removes Organization access without deleting the global account or historical agent work. Password MFA, session lifetimes, and recent authentication govern human access, not background agents or API-key sessions.
Scope credentials and machine access. Managed secrets use encrypted storage and dedicated input fields. Assign supported credentials and destination restrictions at the applicable scope. Mutual-TLS grants can limit destination, method, and path. Private destinations also require operator network policy.
API-key authority. Current Organization read, operate, and manage profiles all grant Organization-wide agent access within the issuer’s current authority. REST and platform Remote MCP recheck the stored scopes and issuer’s active membership and agent authority at request admission. Blocking or revoking a key does not recall accepted work. Confirm the updated authentication and credential writers are deployed together.
Access reviews. A completed certification review records an assessment of members, roles, Team access, and authentication posture. Marking an entry “Needs action” does not revoke its permissions; remediation is a separate authorized change.
03 / Operation classes
Choose autonomy operation by operation.
Import a supported OpenAPI specification, then classify each exposed operation. Exclude the ones the agent must not use.
- Read: runs within the access and credentials you assign
- Autonomous write: no per-call approval; you authorize the policy
- Approval-required write: an approver reviews the exact operation and arguments
Compare operation classes, details and limits
Curate the operation catalog, and bind credentials and approvers before publishing. Native apps, external MCP tools, and browsers have their own controls.
| Operation class | How authority is established | Human involvement | Evidence available for review |
|---|---|---|---|
| Unavailable / excluded | An operation is unsupported, unpublished, excluded from the catalog, or unavailable to the agent’s binding. | It cannot run through this governed integration. Human approval does not make an unsupported operation available. | Inspect a recorded denial or configuration history where captured. Absence of a record does not prove no alternate path was used. |
| Read | An administrator exposes a supported read operation and assigns the applicable credential, grants, and destination access. The underlying provider account remains part of the boundary. | The documented path for this class does not include per-call approval. People establish access and permitted use before the agent runs. | Recorded tool activity and outcomes may appear in the work timeline or Agent Audit View. Provider-side records remain separate. |
| Autonomous write | A supported OpenAPI operation is explicitly exposed as an autonomous write and bound to an authorized credential and agent. | No per-request Decision Terrain approval occurs for this class. The customer authorizes the operation policy and underlying account permissions. | Available activity and enabled audit records may show the request and outcome. Confirm capture for the configured path. Inspect provider records when needed. |
| Approval-required write | A supported OpenAPI operation is classified as approval-required and bound to credentials and configured approvers. | An eligible configured approver reviews the exact operation, arguments, and context. Changes or expiry can invalidate approval. Organization security policy remains authoritative even after tool approval. | Available activity and enabled records may show the proposed action, decision, and outcome. Those details must have been captured and retained. |
| Unsupported or out of scope | The documented OpenAPI or email approval path does not establish authority. Browser actions and third-party writes are not automatically covered by the same mechanism. | Prevent or redesign the workflow, or use a separately evaluated control. A prompt instruction to ask first is not a technical gate. | Decision Terrain may hold partial activity or a capture gap. Review external system records and document what cannot be reconstructed. |
Classify the actual execution path. Exact-call OpenAPI review does not automatically cover native Google Sheets writes, external MCP tools, or browser activity. Covered email has a separate, deployment-enabled Review Before Send policy: reviewers approve the saved message version, and approval queues delivery rather than proving receipt.
04 / Security rules
Publish policy for the activity it covers.
Where enabled, Owners, Admins, and Security Admins can govern selected outgoing content, destinations, tool arguments, incoming messages, and returned results for Organization agents.
Monitor or Block
Monitor records a finding while work continues. Block prevents a covered outgoing action.
Review the held occurrence
Authorized reviewers can recheck held content, or allow one exact matched occurrence with a recorded reason.
Details and limits
Sandbox HTTP-response inspection has separate availability and enforcement boundaries.
Draft, test, publish. Edits stay in a draft until an authorized administrator publishes an immutable revision. Test representative samples without dispatching messages, creating production findings, or sending alerts. Publishing changes active policy; it does not recall an admitted action or replay a denied write.
Monitor or Block. Monitor records a finding while work continues. Block prevents a covered outgoing action. Supported incoming messages or tool results can pause agent execution for a match or unavailable check until all applicable holds clear. Block publication and input/result handling require their deployment controls.
Review the held occurrence. Authorized security reviewers can recheck held content after a policy or inspection repair, or allow one exact unchanged matched occurrence with recent authentication and a recorded reason. Missing, unreadable, or unsupported content requires repair and recheck. Allowing one occurrence does not override other rules or future revisions.
After dispatch. A returned-result hold cannot undo the tool that produced it. Incoming checks govern actions and outgoing content; the working model may already have seen the input. Separately enabled sandbox-response Block withholds content from code after upstream dispatch and creates no whole-agent input hold.
Separate decisions. A finding records inspection and triage. Acknowledging or resolving it does not release execution. An access-review decision does not change permissions. Agent halt and human recovery are separate controls.
Detectors have coverage and inspection limits; an empty findings list does not prove complete checking. The recorded denied-send investigation shows one covered policy denial, with its original local-demo scope.
05 / Reach and containment
Limit what agents can reach. Stop them when you need to.
Tool policy narrows what every agent in an Organization or Team can use. Blast radius shows what one agent could reach. Security holds stop an agent, a Team, or the whole Organization, and only authorized people release them.
Organization and Team tool policy
Deny tools, MCP servers, and custom tools for every agent in scope. A lower scope cannot re-allow a denial.
Blast radius
See what an agent has used, could use next, and is one human step away from, with links to the controls that reduce each path.
Watch the 52-second blast radius demoSecurity holds
Hold one agent, a Team, or the whole Organization as one incident. Only an authorized person releases it.
Vendor access record
See actions recorded for Decision Terrain support administrator accounts on each agent.
Details and limits
Security holds, Team and Organization holds, and blast radius are deployment-gated. Confirm availability for your deployment; the security review materials list the status of each control.
Organization and Team tool policy. Owners, Admins, and Security Admins can deny built-in tools, MCP servers, individual MCP tools, and custom tools for every agent in an Organization or one Team. A lower scope cannot re-allow a denial. Checks read current policy on every call, and a policy-read failure refuses the call. Each change is recorded. There is no allowlist-only mode.
Blast radius. Where Agent Audit View is enabled, an agent profile shows what the agent has used, what it could use on its next turn, and what is one human step away, across people, model providers, communication, web, code execution, integrations, and data. Each path links to the control that reduces it. The view reads saved configuration and retained records only. Watch the blast radius demo.
Security holds. Where enabled, Owners, Admins, Security Admins, and Agent Admins can place a hold on an agent; Owners, Admins, and Security Admins can hold every agent in a Team or the Organization as one incident. A hold terminates running execution and fences queues and schedules. Release needs recent authentication, the exact agent name, and acknowledgement of unconfirmed outcomes.
Vendor access record. An agent profile lists actions recorded for Decision Terrain support administrator accounts on that agent, from snapshots taken at the time. This is visibility, not an approval gate, and ordinary opens through membership are not logged.
Hold boundary. A hold cannot recall an action an outside service already accepted. Work that cannot be shown to have stopped is reported Unknown, and the hold reads Partially enforced until it is resolved or acknowledged. Holds are not an emergency shutdown of the deployment.
Policy boundary. Denying one code tool does not remove code execution while another code-capable tool stays available. A denial does not cancel an already-dispatched call. Personal workspace agents are outside Organization tool policy.
06 / Audit evidence
Use the right record for the question.
The security ledger, Agent Audit View, work timeline, and external-provider records answer different questions. Inspect them together.
- Security ledger: covered administrative changes
- Agent Audit View: runs, actions, authority, outcomes, and coverage
- Work timeline: surrounding activity, not a complete audit trail
Details and limits
Inspect records within enabled capture, reviewer permissions, and retention.
Administration and execution. The security ledger covers specified administrative changes. Agent Audit View covers instrumented runs and actions, including recorded authority, decisions, outcomes, and coverage. The work timeline supplies surrounding activity; it is not a complete audit trail.
Protected evidence. Full evidence is optional, prospective, and separately controlled. It must have been captured and retained before an authorized reviewer can reveal or export it. A link to a record does not grant access to its protected content.
Provider and export boundaries. A platform-observed success needs independent receiving-system checks when delivery or business completion matters. Metadata and protected evidence have separate retention. Cleanup cannot erase provider records or previously downloaded copies.
Enabling capture cannot recreate earlier missing content. Preserve unknown outcomes and coverage gaps; an event hash does not prove completeness.
07 / Security operations
Connect agent oversight to your security stack.
Forward selected audit events to your SIEM, and let your security tools request a hold on an agent. People keep the release.
Forward audit events to your SIEM
Send selected audit events to Splunk, Microsoft Sentinel, Wazuh, or custom OTLP through the route enabled for your deployment.
Let your SOAR or XDR request a halt
A security tool with its own scoped identity can hold one agent and read the enforcement status. It cannot release the agent.
Keep release with people
Only an authorized person can release a halt, with a recorded reason. Release does not replay cancelled work.
Watch a security tool halt an agent and a person release it (57 seconds) · Compare SIEM routes and verification
Details and limits
Configure scoped external response independently when your security workflow needs an agent hold. These paths retain the human review and permissions described above.
Forward audit events to your SIEM. Eligible Organizations can configure independent destinations through deployment-gated managed forwarding. Legacy installation OTLP and the standalone operator bridge remain distinct routes. Supported mechanisms cover Splunk, Microsoft Sentinel, Wazuh, and custom OTLP. Selected agent-audit and Organization-security projections exclude full evidence; receiver acceptance, provider submission, and indexed-field confirmation are separate checks.
Let your SOAR or XDR request a halt. A security tool authenticates as its own service identity, with a scoped credential and an explicit list of agents it may act on. It can request a durable halt on one agent and read the enforcement status. It cannot release the agent, run agents, or use ordinary agent APIs.
Keep release with people. Only an authorized person in your Organization can release a halt, after recent authentication and a recorded reason. Releasing does not replay cancelled work, restore revoked access, or resume stale approvals. Continuing requires deliberate new work.
Halt boundary. An accepted halt commits admission barriers and requests cancellation where supported. Acceptance does not prove every process stopped; inspect enforcement status, worker acknowledgement, and unresolved work. It cannot recall actions already completed or accepted by an external system, and the status can report an outcome as unknown. Check the returned enforcement status.
Integration boundary. Managed forwarding requires coordinated deployment, Organization eligibility, authorized roles and explicit destination activation. First acknowledged activation switches future Organization routing; existing legacy deliveries drain to their original collector, and managed failure never falls back. Source capture, retention and possible duplicates still apply. External response has separate prerequisites and uses a vendor-neutral API called by your playbook; forwarding activation does not enable it.
08 / Operating practice
Turn configured controls into a reviewable workflow.
You set information policy, authorize accounts and integrations, and assign reviewers. Platform operators run the services that enforce those boundaries.
Review the proposed environment
Review identity setup, data flows, network paths, evidence capture, retention, and recovery with your security team. These capability descriptions do not assert a certification, authorization, or blanket compliance status.
Review deployment dependenciesTest representative work
Test permissions, denied paths, approval expiry, failure cases, evidence capture, and recovery before expanding use.
Threat and risk review. Use the OWASP agentic security checklist to examine agent-specific attack paths. Use the NIST AI RMF checklist to record wider governance and risk-management evidence.
Decision record. Use the AI technology evaluation scorecard to record requirements, available evidence, open questions, and the reasons behind an evaluation decision.
Embedded product fit. If DT will sit behind another product or customer solution, evaluate the integration, control path, evidence, and operating responsibilities together.
Details and limits
Customers set information policy, authorize accounts and integrations, and assign reviewers. They also decide what work is appropriate. Platform operators configure the infrastructure and services that enforce the agreed boundaries. Assign the work, inspect the configured decision and recorded outcome, then authorize remediation separately. Include provider terms and operating ownership in the environment review. Document the operations and execution paths you tested, including credential changes.
Prepare before activation. Create an inactive agent when tools, credentials, schedules, or review must be set up first. Active creation can request initial processing and a separate first check-in even when the primary schedule is null. Cooperative Stop, deactivation, security-rule holds, and emergency halt have different boundaries.
09 / Frequently asked questions
Questions to resolve before enabling consequential actions.
Answers describe the documented control paths on this page. Confirm the enabled features, integrations, and deployment configuration for the workflow you are evaluating.
01What AI agent actions can require human approval?
Configured governed OpenAPI operations can require exact-call approval. Covered external email has its own Review Before Send control when enabled. These controls do not automatically gate native Google Sheets writes, external MCP tools, or browser actions. Evaluate each execution path separately.
02Do charters and instructions enforce permissions?
Charters and instructions guide the agent’s responsibility and expected behavior. Technical boundaries come from supported access grants, credentials, destination restrictions, operation policies, and covered security rules. An instruction to ask first does not create an approval gate.
03What is the difference between Monitor and Block?
Monitor creates a finding while work continues. Block prevents a covered outgoing action or holds supported incoming messages and tool results until applicable holds clear. Separately enabled sandbox-response Block withholds content after upstream dispatch; it neither undoes the remote action nor creates a whole-agent input hold. Resolving a finding does not release held work.
04What information is recorded about an agent action?
The security ledger records covered administrative changes. Agent Audit View records supported runs, actions, authority, outcomes, and coverage. The work timeline provides activity context; providers keep separate records. Capture, permissions, and retention determine what can be inspected or exported. Review audit records and coverage.
05Can API responses be redacted before reaching an agent?
Yes, for configured supported response fields on governed OpenAPI integrations. Administrators select the redaction paths. This control applies to that imported API path and response shape; it does not transform every tool result.
06How do SSO and SCIM work with Decision Terrain?
Deployment-enabled SAML 2.0 or OpenID Connect SSO requires domain verification, provider testing, and activation. SCIM manages Organization membership and supported group mappings; deactivation removes Organization access without deleting the global account or historical agent work. Password MFA and browser session policies are distinct from API-key authority and background execution.
07Can Decision Terrain send audit data to our SIEM?
Eligible Organizations can maintain independent destinations through deployment-gated managed forwarding. Legacy installation OTLP and the standalone operator bridge remain distinct routes. Selected agent-audit and Organization-security projections exclude full evidence. Capture, activation, retention, and duplicate-delivery limits apply. Collector receipt and provider submission do not prove indexed fields. External response is configured independently. Compare SIEM routes and verification.
08Can our SOAR or XDR stop an agent?
Where independently enabled, a security tool can request a durable hold through a vendor-neutral API with its own service identity and explicit agent allowlist. Acceptance commits barriers; it does not prove every process stopped. Inspect enforcement status and unresolved work. Only an authorized person can release the hold. Completed or provider-accepted effects cannot be recalled.
09Does running DT on our own infrastructure mean the system is offline?
Running on your own hardware or cloud account alone does not keep inference, integrations, email, browsers, or telemetry inside the boundary. A supported air-gapped configuration places required services internally and replaces or disables external dependencies. A public-cloud Sentinel route requires external connectivity. Review disconnected deployment dependencies.
10Can we restrict tools for every agent at once?
Yes. Organization and Team tool policy denies built-in tools, MCP servers, individual MCP tools, and custom tools for every agent in scope, and lower scopes cannot re-allow them. Agent owners can add further per-agent denials. There is no allowlist-only mode.
11Can we see what a compromised agent could reach?
Where Agent Audit View is enabled, the blast-radius view groups an agent's observed, currently reachable, and dormant paths by area and severity, with links to the controls that reduce them. It reads saved configuration and retained records; it does not test provider access. Review audit records and coverage.
12Can we see what Decision Terrain staff did on our agents?
An agent profile lists actions recorded for Decision Terrain support administrator accounts, including configuration changes, emergency-control steps, and staff-privileged access. It is visibility rather than an approval gate, and access through ordinary membership is not logged.
Next step
Map the controls for one consequential workflow.
Bring one proposed agent, its tools, data, and highest-risk actions. We’ll walk through permissions, approval points, available evidence, and deployment dependencies.