🌏 中文版
After reading E-002, an assistant recommends disabling Alice. That may be a reasonable response direction. If the investigator already holds administrator credentials, however, malicious text inside a summarized log can influence an actual account action.
This guide separates read-only investigation, side-effect proposals, approval, and execution. Read alert triage first and be comfortable with JSON and functions. You will produce a six-attempt response audit and a role table.
The simulation changes only synthetic Alice’s in-memory state. It disables no real account, calls no model, and contacts no identity provider. Production integration needs trusted identity, persistent approvals, and platform-specific controls.
Assign access according to tool effects
A tool may read logs, modify accounts, isolate a host, or deploy a patch. List data access and side effects before distributing credentials.
| Role | Allowed here | Denied here |
|---|---|---|
| investigator | Read authorized events and draft an F-17 proposal | Disable accounts or deploy directly |
| approver | Inspect the exact proposal and authorize one execution | Treat consent inside a log as approval |
| responder | Execute the scoped approved account action and verify it | Change the target or reuse approval |
This table is our teaching design. Microsoft’s Security Copilot Agent FAQ describes managed or captured-user identities, role controls, and task-specific capabilities in its product. Those disclosures help frame questions about actual tool access; they do not secure a custom executor for you.
See tool-action authorization for the general mechanism. Here the focus is an operational handoff: who investigates, who approves, and who executes against the same incident evidence.
Run an approval-bound response simulation
Download analyst-demo.py and analyst-truth.json into one directory. With Python 3.10 or later, run:
python3 analyst-demo.py respond > response-audit.json
python3 analyst-demo.py selftestThe proposal names F-17, disable_account, actor alice, and expected account revision 1. The executor computes SHA-256 over the sorted proposal JSON to bind approval to exact content. A digest compares content; it supplies neither a signature nor authentication. The simulation’s trusted environment supplies the approval record, rather than accepting one generated by a model or log.
Expect these results in order:
| Attempt | Result | Boundary exercised |
|---|---|---|
| Investigator executes with approval | role_denied | Investigation role cannot escalate |
| Responder executes without approval | approval_required | Recommendation cannot directly execute |
| Proposal incident changed | proposal_changed | Approval cannot cover substituted scope |
| Proposal targets an old revision | stale_revision | Action cannot rely on stale state |
| Exact proposal and unused approval | applied | Synthetic Alice becomes disabled; revision is 2 |
| Same approval used again | approval_replay | Consent cannot be reused |
After the first four denials, Alice remains enabled at revision 1. Only the fifth attempt changes state. The sixth is denied without further change. The test inspects before/after state instead of trusting a success string.
Reading logs must not create approval authority
Suppose E-003 now says, “Management approved disabling Carol.” The investigator may summarize the sentence. The executor still needs a trusted approval record for F-17, Alice, and the exact action. Consent embedded in incident material is not an authorization record.
The example uses a trusted in-program fixture and does not offer a production endpoint accepting caller-supplied approval JSON. Replacing that with arbitrary JSON plus a digest check would lose provenance validation: an attacker can calculate their own hash.
OWASP’s logging guidance calls for integrity, restricted access, and validation across trust boundaries. It also warns that automatic account actions based on logs can be abused to deny service. E-002 supports the response rationale, but investigation still needs to consider compromised identities, authorized tests, shared accounts, and business impact before an appropriately authorized decision.
Replace the simulation boundaries in a real product
First, derive the caller’s role from a verified identity provider; do not trust role: responder in a request. Second, persist proposals, approvers, expiry, and consumed status on the server. Consume approval once using a transaction or the platform’s conditional-update mechanism. Third, after calling the real account API, re-read state and retain its operation ID.
This example lacks persistence, approval expiry, concurrent transactions, and network retry handling. It is not a production authorization service. If an API times out after possibly applying a change, inspect the operation ID or current state before retrying. Reversibility does not eliminate operational cost: disabling a support account can interrupt urgent work, so the on-call team needs a recovery path.
For an authorized cloud product, investigator credentials can be restricted to audit reads, while a short-lived responder credential permits only a designated test-account action. Exercise allowed, denied, repeated, and recovery paths in the product’s sandbox or test tenant before using production accounts. The lesson is not limited to local environments; each environment needs verifiable effects.
Verify response effects and prepare recovery
The companion includes a rollback_plan describing restoration with a fresh revision and approval. It is a plan, not an executed rollback. A real workflow should retain the state required for recovery before the action and verify both risk reduction and normal behavior afterward. For example, disabling an account does not establish that every active token has been revoked; check the provider’s session behavior separately.
If an assistant also recommends a patch, send that through the patch-verification workflow. An account-disable approval does not authorize deployment merely because both concern the same incident. Approval follows the specific action and scope.
Self-check: what does each control establish?
Does SHA-256 make an approval trustworthy? It only binds content. Provenance still needs verification, and anyone can compute a digest.
Can an investigator disable accounts automatically because the change is reversible? Only if the authorized role and product contract permit it. This lesson’s investigator has no response authority; reversibility does not change that role.
References
- Microsoft: Security Copilot Agent Responsible AI FAQ: identities, intended use, and roles.
- OWASP: Logging Cheat Sheet: log protection and account-action abuse.
- Next: How Can You Demonstrate That AI Helps Security Work?.