Stop Unsafe Production Actions Before Execution
Intercept shell commands, infrastructure changes, permission updates, and destructive database operations before a production side effect occurs.
What this path changes
The host receives an explicit policy disposition before the privileged tool is called and can permit, hold, or block the action.
The action, boundary, and evidence
Who owns the risk
Platform engineers, AI engineers, security architects, and CISOs responsible for privileged agent tool access.
When the gate runs
An agent proposes a shell command, deployment, infrastructure mutation, permission change, credential operation, or destructive database action.
How to configure assurance
Use deterministic 5D policy for explicit prohibitions and thresholds. Add Jev, another contextual LLM, or both when intent needs semantic interpretation. Observer evidence never clears a deterministic block.
- Run a privileged shell command or copied command from an untrusted page.
- Delete storage, mutate production data, or deploy unreviewed code.
- Change IAM permissions, rotate credentials, or open network access.
- A gated-versus-ungated interception test proving the tool is not called on block.
- Blocked-action receipts, failure-path tests, latency overhead, and a documented bypass boundary.
Next: Test a privileged-action policy against a non-production tool path.
Follow a matching proposed action through the gate.
Synthetic tested action under the pinned 5D 0.7.0 illustrative policy.
Drop a live database while repairing a migration
The agent mistakes the live target for a disposable test environment. Under the pinned illustrative policy, the expected result is that the action is ineligible for execution.
- Tool
- database.execute
- Target
- live primary database
- Purpose
- repair migration
5D suppliesA deterministic RED decision before the call.
Host ownsRouting every database executor through the gate and refusing the call.
Coverage limitA direct or alternate database path bypasses this gate.
Where this control fits in the governance lifecycle.
These references identify possible technical-evidence contributions. They do not mean every framework applies to every deployment.
This mapping identifies possible technical-evidence contributions. It is not legal advice, certification, conformity assessment, readiness scoring, a compliance conclusion, or proof that an AI deployment is safe. Applicability, governance, integration coverage, and deployment outcomes remain the organisation's responsibility.
Bind and deploy
Which approved control covers each execution path?
Dimension 3 — Implement technical controls and processesControl access to approved tools and services
What 5D helps with: Gateways and adapters can attach action policy to documented tool-call paths.
What 5D does not establish: The host must prove complete interception, authenticate identity, secure configuration and operate the surrounding controls.
Official source ↗ASI02 Tool Misuse and Exploitation — mitigation 1; ASI03 Identity and Privilege AbuseLeast agency, tool boundaries and privilege context
What 5D helps with: 5D can enforce one declared tool-policy boundary using caller-supplied identity and authority context.
What 5D does not establish: 5D does not mitigate the complete ASI risks, authenticate identity, validate grants or guarantee complete action-path interception.
Official source ↗Enforce at action time
May this proposed action cross the boundary?
Articles 9(5)–(6), 14 and 15(1), 15(4)Risk treatment, human oversight, robustness and cybersecurity
What 5D helps with: Pre-action prohibitions, routing and a policy-selected human hold can implement one technical risk-treatment measure.
What 5D does not establish: Only relevant where these duties apply to the actor and system; 5D does not establish the wider risk system, oversight design, robustness or cybersecurity.
Official source ↗MANAGE 1.2–1.3Prioritise and document risk treatment
What 5D helps with: Permit, hold and block policy can implement one documented treatment for selected action risks.
What 5D does not establish: 5D does not prioritise organisation-wide risk or determine risk acceptance and treatment sufficiency.
Official source ↗Gate a function
from fivedrisk.hooks import gate
@gate(tool_name="write_to_database", autonomy_context=2)
async def write_record(table: str, data: dict) -> None:
...Written for fivedrisk==0.7.0. Verify against the immutable source and public documentation before use.
Intercept the proposed action
Wrap the tool entry point or use a supported framework hook so the policy check runs before the side effect. Supply the tool name, arguments, autonomy context, and any identity or destination context required by policy.
Resolve clear cases in code
Manual score() returns an inspectable band. The @gate decorator executes GREEN and YELLOW paths, while ORANGE and RED raise or invoke the configured on_block handler. The host must supply any review workflow and must keep alternate execution paths behind the same boundary.
Keep enforcement in the host
The application must honor the result, route approval-required cases, and refuse unresolved actions. A bypass around the wrapped path remains a bypass around governance.
What this page does not establish
- The gate evaluates the action context it receives. Missing or inaccurate context weakens the decision.
- Coverage depends on wiring every relevant execution path through the gate.
- The verdict addresses action risk, not whether the agent's goal or reasoning is correct.