The workload's effective access after the change, read from the access tool.
Workflows · Security containment
Workload isolation stops for the Security operations owner.
When a CC7.2 alert fires, show the workload, the containment action, the evidence, and the decision owner before isolation, then read the access change back.
Example workflow. Execution requires a configured tool with provider permissions for this action; see the connection’s operation reference or bring your company tool to the demo.
Agent request
Remove production access from workload checkout-worker-17
The containment action can stop a production workload from reaching required services.
- Identity
- response-agent · Security operations
- Target
- production/checkout-worker-17
- Cost
- Recorded agent cost
- Evidence
- Workload identity, current access, and containment reason
SOC 2 CC7.2
Sensitive: waits for a named approver.
The workload identity, the access before and after, the containment reason, the Security operations owner's reason, and the CC7.2 alert it answers.
Policy decision
Production workload isolation requires the Security operations owner.
Security operations owner
The action waits until this owner approves or denies it.
Tool call resumes
The access tool applies the approved containment change and records the result.
Tool call stays blocked
The workload keeps its current access and the containment call does not run.
Execution order
The agent request stops before the connected tool runs.
- 01Response agent requests workload isolation
- 02Deixic checks the workload, access change, evidence, and policy
- 03Security operations owner decides
- 04Connected access tool returns the containment result
- 05Deixic reads the result back and attaches the receipt to the test
Activity history keeps the request, decision, cost, and result.
Keep the procedure for the next request.
Keep the policy and decision history, save the steps and evidence as a skill, and test changes on real sessions; an approval stays specific to its request.