SIEM Audit Forwarding and Security Response

External security connects Decision Terrain with your SIEM, SOAR, or other security tooling. Choose audit forwarding, security response, or both. Forwarding works without creating response credentials or enabling agent halts.

Audit data:  Decision Terrain → audit collector → SIEM
Response:   SIEM or SOAR → scoped Decision Terrain API → agent hold
Recovery:   authorized human → release the hold in Decision Terrain

Choose your setup path

Goal	Start here	Who configures it
Monitor and investigate audit events	Configure audit forwarding below	Installation staff, Organization administrator and SIEM administrator
Let external security tooling request an agent halt	Enable security response, then create a scoped identity below	Installation operator, Organization administrator, and integration developer
Forward events and enable response	Verify forwarding first, then configure and verify response separately	All three responsibilities

An Organization role grants access to the permitted product controls. It does not grant access to the application host, database, or provider account.

Each Organization can maintain multiple independent destinations through Governance → Policies → External security → Audit forwarding using the automatically provisioned managed service. Fresh installations allow all Organizations to configure forwarding; a saved selected-Organization restriction may require staff review. Owners, Admins and Security Admins manage forwarding; Auditors inspect sanitized settings and delivery status. SSO and recent authentication apply to changes. The existing installation-wide collector remains the legacy route until the first managed destination is acknowledged.

Set up audit forwarding

Location: External security → Audit forwarding. Choose Add destination, select a provider and audit families, and enter its endpoint, credentials and trust settings. Save, validate and send a synthetic test; activate collection when ready. New destinations start disabled and select both families. Staff first prepares service eligibility, enrolled Wazuh collector bindings or assigned Azure managed identities. Provider infrastructure is configured in its own console; see SIEM audit forwarding for Splunk, Microsoft Sentinel and Wazuh.

Destination controls, including synthetic tests and activation, and saves to destinations with an effective configuration require independent human security-policy approval. A pending review has not applied the change. A different authorized administrator reviews it in Governance → Policies → Tool access → Execution protection → Security policy changes, then the original requester repeats the exact action. Follow the forwarding change review procedure for the full scope, expiry and testing exception. Recent authentication still applies.

Agent events include bounded summaries and selected execution metadata. Organization security events use categorical bodies and approved identifiers, including selected service-identity and intervention evidence. Neither stream exports full evidence, prompt/tool bodies, or every independent audit ledger. Existing capture gaps and retention still apply. Review Audit and evidence for investigation in the product.

Finish setup by finding a known event in the actual provider search interface and checking its event ID, Organization, outcome, and original occurrence time. A configured connection or collector acknowledgement alone does not establish searchable indexing.

Maintain forwarding

Each destination card leads with status badges (Collecting or stopped, Sending paused, Changes not applied yet, Needs attention), then shows pending, accepted, failed and quarantined counts, how long ago work was last submitted, indexed and checked, desired/applied revisions, delivery errors and recent operations. The next step is the highlighted button (Activate collection for a new destination); Pause sending, Preview provider retry and Retire are under More. Stop collecting affects future capture; Pause sending retains backlog and keeps collecting. Edit configuration to replace credentials or trust. For output identity changes, stop collecting, drain outstanding work and obtain a fresh status check before editing, then reactivate after publication; alternatively create a replacement. Retire keeps recovery available.

Delivery recovery previews a selected family and time range of up to 31 days. Apply each page before advancing. Replay creates missing deliveries; retry resets eligible failures. Neither resends accepted/indexed work. Preview provider retry and Apply provider retry recover the exact observed batch of blocked provider failures. Synthetic tests are labeled and never substitute for actual product events in provider search. Custom OTLP and Splunk without search credentials show submission only; downstream indexing is unknown.

Optionally create a response identity

Location: Decision Terrain UI. An Owner, Admin, or Security Admin can manage response identities. Auditor can inspect identities and interventions but cannot create credentials or release holds.

1. Select the Organization and open Governance → Policies → External security → Response access. After staff grants eligibility and completes deployment setup, choose Enable external response. Confirm external access is enabled; the new-identity form appears only then.
2. Enter an Integration identity name. Use one identity per integration so credentials and event attribution stay independent.
3. Select Authorized agents. Select every Organization-owned agent this integration may halt and inspect; there is no Organization-wide wildcard.
4. Select Read agent and intervention status (security:read), Request agent halts (security:halt), or both, then choose Create identity and token. Read-only access is the default. A sender that creates holds and polls status needs both.
5. Save the One-time bearer token in the integration's secret store, using Copy token if needed. Choose I saved it to dismiss it. The raw token is not returned on subsequent reads.
6. Give the integration developer the scoped agent UUIDs and the response API guide. Configure the provider or a trusted relay to send the exact supported JSON with bearer authentication.

The installation deployment ceiling still applies. Disabling response blocks new external authentication and halt admission while retaining identities and existing interventions. Human release and cleanup retry remain available in Interventions even when Organization or installation response is disabled.

The response screen distinguishes the saved Organization policy from effective external access. It reports the installation ceiling, Organization eligibility, dedicated credential-pepper readiness and HTTPS enforcement. You can disable a saved policy while installation response is off. If enablement is unavailable, have installation staff check the reported prerequisites, and check your role. Forwarding can still be configured while response is disabled. There is no general Organization API-key substitute for a security service token.

Maintain credentials

Location: Decision Terrain UI. Each identity lists its permissions, agents, enabled state, and active credential's last-used time.

Control	Effect
Disable / Enable	Stops or permits identity authentication on subsequent requests
Rotate credential	Immediately invalidates the old token and shows a replacement once; update the integration's secret store
Revoke credential	Invalidates the active token; use rotation to issue a new one

Disabling an identity or revoking its credential leaves its existing holds active. Credential changes and release require recent Organization authentication and applicable SSO. A missing last-used timestamp is not a provider connectivity test.

Use Edit name and access to change its name, explicit agent scope or permissions. Existing tokens use current permissions and scope immediately after the update. Scope edits serialize with halt admission. Existing holds and idempotency records retain their original identity attribution. Removing an agent from scope also prevents status reads and event replays for that agent; it does not release the hold.

Read permission covers known interventions for each authorized agent, including holds created by other identities or DT operators and their recorded reason/reference. It is not limited to that identity's own incidents. Credential last-used time is sampled on authentication at roughly five-minute intervals; it is not evidence that a halt was accepted or enforcement completed.

Enable and disable transitions retain the audit actions security_service_identity_enabled and security_service_identity_disabled for existing detection rules. Name, permission and scope changes emit security_service_identity_updated. Repeating the current enabled state preserves its original disable attribution and creates no additional event. Empty edits are rejected.

Review interventions

Location: Decision Terrain UI. The Interventions list shows the affected agent, requesting identity, state, acceptance time, dispatch barrier, worker acknowledgement, unresolved-work total, and any recorded reason or incident reference. It refreshes periodically.

The current list shows at most the 200 most recently accepted interventions across the Organization, including released holds, with no pagination. An older active hold may therefore be absent. Retain accepted intervention IDs and use the scoped API's target control state to inspect all active IDs; do not treat the UI list as a complete inventory.

Acceptance means the hold is durable. It does not mean every action stopped. An already admitted external request can complete remotely or remain unknown. Inspect the barrier and worker evidence separately from the lifecycle state; the API guide explains the states and counts.

Several incidents can place independent holds on the same agent. Removing one does not remove the others. Disabling a provider automation or closing its incident also does not release the DT hold.

Read in-flight work and cleanup

Location: Decision Terrain UI. Each intervention, each halt-group card and the personal-agent danger zone show what became of work that was already running when the hold was placed. A server that predates this display omits the fields and the page then shows nothing extra. The display adds no control and changes no release rule.

Display	Meaning
Cancelled	Work that is proven stopped, or shown never to have started or taken effect
Unknown outcome	Work that could not be proven stopped or harmless. It is not a failure and it is not a success; it is never retried automatically
Failed to stop	Work that failed, including work DT owns that it could not show had stopped. In the second case cleanup stays Not verified and the final hold cannot be released until a retry succeeds
Still stopping	A stop has been requested or is pending
Finished on its own	Work that completed normally
Outside-service cleanup	Not applicable, Checking, Verified or Not verified: whether work running against outside services was stopped and its absence checked. Verified does not recall anything an outside service already accepted

Under each count, How in-flight work can be stopped lists, for the work the hold tracked, how many items fall into each class and how many are unresolved:

• Process we can end: DT runs the work in a process it owns, ends it and checks its absence on the host that ran it. This is how a running browser task is stopped. Actions the browser already took are not undone, and a browser task stays Unknown unless its process is shown to be gone.
• Connection we can close: DT closes the network connection for one request (an approved API call, an email send, a webhook delivery, a mailbox read, a model call made outside the agent's own run). The other service may already have received it, so a request that could change something there reads Unknown unless the service confirms.
• Provider can cancel: the provider has a cancel call. The work counts as Cancelled only after the provider confirms; a cancel the provider merely acknowledges does not count.
• Cannot be cancelled, only fenced: new work of this kind is blocked, and anything already started reads Unknown unless it can be shown to have had no effect.

What the hold stops depends on how your installation is deployed. Browser tasks are terminated only where the dedicated browser worker runs; per-agent stops of the shared webpage fetcher and egress proxy need the attribution key and control services your installation operator configures; connections are closed only where the supervised runtime is enabled. Browser tasks started without a persistent agent, inbound message handling and platform housekeeping are outside the hold. Work that finishes after the hold is recorded as evidence but never shown to the agent. A closed connection or a recorded time never proves the other side stopped, and no stop is guaranteed within a fixed time.

Halt an agent from the console

Location: Decision Terrain UI. Without any external integration, an Owner, Admin, Security Admin or Agent Admin can place a security hold on an Organization-owned agent. Agent Admin can halt only agents it manages. Auditor, License Admin, Identity Admin, Member and Viewer cannot.

1. Open the agent's settings and choose Halt agent in the danger zone, or open Governance → Policies → External security → Interventions, choose the agent under Halt agent, and choose Halt agent….
2. Enter the Reason and, optionally, an Incident reference. Keep secrets and personal data out of both; they are shown to people who can open Interventions.
3. Confirm that you understand the hold and choose Halt agent. No re-authentication is required, and repeating the request returns the existing hold.

Active Owners and Security Admins receive a generic email that a hold was placed, with a link to Interventions. The email does not name the agent or the reason.

Halting must be enabled by the installation (CUSTOMER_SECURITY_HALT_ENABLED); there is no per-Organization switch, and roles decide who can halt. When it is unavailable the control says why. Turning it off never blocks reviewing, retrying or releasing an existing hold.

A security hold is not Emergency Shutdown. It does not recall effects an external system has already accepted. A browser task or webpage or media fetch that is already running may not stop: whether it is terminated depends on how your installation is deployed (see what a hold can stop), and work that is not shown to have stopped is reported as Unknown. Review the lifecycle state (accepted, enforcing, enforced, partially enforced or failed) and any unknown or unresolved work before releasing. Releasing uses the steps below and stays limited to Owner, Admin and Security Admin.

Halt your own personal agent

Location: Decision Terrain UI. If an agent lives in your own personal workspace (it does not belong to an Organization), you can place a security hold on it yourself from the agent's settings; no support request is needed. Only the agent's owner can do this. Collaborators cannot.

1. Open the agent's settings and choose Halt agent in the danger zone.
2. Enter the Reason (keep secrets and personal data out) and confirm. No re-authentication is required, and repeating the request returns the existing hold.
3. When cleanup is verified, choose Release hold. Releasing needs a recent sign-in, a reason, the exact agent name and an acknowledgement that work interrupted by the hold may have unresolved or unknown outcomes. Work cancelled during the hold is not replayed.

If Decision Terrain support placed the hold, the settings show Held by platform support and you cannot release it yourself; contact support. Support can release either kind. You receive a generic email when you place or release a hold. A personal agent that is on hold cannot be moved into an Organization or transferred until it is released.

Personal halt uses the same installation setting (CUSTOMER_SECURITY_HALT_ENABLED) as the Organization halt and has the same limits: it is not Emergency Shutdown, does not recall effects an external system has already accepted, and a browser task or fetch that is already running may not stop (see what a hold can stop). Halting only one agent at a time is supported.

Halt a Team or the whole Organization

Location: Decision Terrain UI. An Owner, Admin or Security Admin can hold every active agent in the Organization, and an Agent Admin every agent in a Team it manages. The agents are held one by one under a single halt, so each hold behaves like a single-agent hold and can be reviewed in the halt's progress view.

1. Open Governance → Policies → External security → Interventions and find Halt multiple agents.
2. Choose Entire Organization or One Team, enter a Reason and an optional Incident reference, and choose Review impact.
3. Check the impact: how many agents are in scope, how many are running now or have pending approvals, which are already held, and which are not covered (paused and deleted agents are held later if they are reactivated or restored). If the agents changed while you were reviewing, the page shows the new impact and asks you to confirm again; nothing is halted until you do.
4. Type the Team or Organization name and choose Halt N agents. No re-authentication is required.

The halt is accepted at once and holds are placed in the background. The halt's card shows how many agents are held, any that could not be held, the enforcement state and unresolved or unknown outcomes. It is complete only when every agent in scope is held; use Retry agents not held for failures. While a halt is active, agents created, restored, reactivated or moved into the scope are held when they arrive, and moving an agent out of the Organization is refused until the halt is released. Owners and Security Admins receive one generic email per halt.

To end a halt, an Owner, Admin or Security Admin chooses Release this halt…, enters a reason, types the Team or Organization name and acknowledges unresolved outcomes. This releases only the holds that halt placed; any other hold on the same agents (an external integration, a single-agent halt, another halt) stays in place and the agent stays held until the last hold is released. It needs recent authentication and does not replay cancelled tools or resume stale approvals. If some agents cannot be released, the halt remains active (still holding new arrivals) until you retry.

Starting a group halt needs the installation setting CUSTOMER_SECURITY_HALT_SCOPE_ENABLED as well as CUSTOMER_SECURITY_HALT_ENABLED. A group halt is not Emergency Shutdown and has the same limits as a single hold. It is not an atomic switch: an agent is not safe until it shows a hold.

Release or retry a hold

Location: Decision Terrain UI. Only an authorized human releases a hold; external integrations cannot release or set an expiry.

1. Review the intervention and unresolved outcomes.
2. Enter a Release reason and the exact agent name in Confirm agent name.
3. If shown, acknowledge unresolved or unknown external outcomes.
4. Choose Release this hold and complete recent authentication if required.

Failed required cleanup prevents releasing the final hold and reopening admission. Releasing one of several holds leaves the others and the admission barrier active. For failed cleanup, use Retry enforcement and inspect the updated evidence before releasing the final hold. An installation operator may need to resolve a runtime or sandbox cleanup problem.

Releasing the final hold advances the execution generation through verified recovery. It does not replay cancelled work, restore revoked grants, resume stale approvals, or guarantee a remote side effect was undone. Continuing work requires deliberate fresh admission.

Availability and verification

The response API is implemented behind deployment gates. Vendor-specific response adapters and complete live response workflows have not been validated. Successful ingestion at one provider does not establish production acceptance at another or prove successful containment. Your operator must verify the selected path against the exact deployed release.