Prevent Sensitive Data from Leaving the Approved Boundary
Evaluate the destination, data classification, tool privilege, and policy red lines before an agent uploads, emails, or exposes sensitive material.
What this path changes
Known prohibited data-and-destination combinations can be blocked before the external tool receives the request.
The action, boundary, and evidence
Who owns the risk
CISOs, privacy leads, security engineers, and regulated product owners responsible for data movement.
When the gate runs
An agent proposes uploading, emailing, copying, posting, or otherwise exposing information outside an approved boundary.
How to configure assurance
Use deterministic destination, data-classification, and red-line policy. Add a semantic observer only when sensitivity or intent depends on context supplied by the host.
- Send personal or employee records to an external model or service.
- Attach a confidential file to an outbound message.
- Post secrets or transfer regulated data across an unapproved region.
- Allow and block examples covering known destinations and data classes.
- A receipt identifying the controlling rule, plus tests for missing or inaccurate host context.
Next: Inspect a data-egress policy and test it with sample data.
Follow a matching proposed action through the gate.
Synthetic tested action under the pinned 5D 0.7.0 illustrative policy.
Export account-holder records to an external workspace
A broad query and external destination exceed the declared data boundary. Under the pinned illustrative policy, the expected result is that the action is ineligible for execution.
- Tool
- storage.upload
- Target
- external workspace
- Purpose
- produce analysis
5D suppliesA RED decision before external transfer.
Host ownsData classification, destination truth, and enforcement across every egress path.
Coverage limitUnclassified data or an uncovered uploader can bypass the intended boundary.
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.
Define
What may this agent do?
Article 9(2)(a)–(b)Identification and evaluation of known and foreseeable risks
What 5D helps with: The action envelope can make intended actions, authority and foreseeable misuse conditions explicit as technical inputs.
What 5D does not establish: Applies only where the EU AI Act and Article 9 duties apply to the relevant actor and high-risk AI system; 5D does not perform the required risk-management system.
Official source ↗MAP 1.1, 1.5–1.6 and MAP 3.3Context, impacts, requirements and intended-use mapping
What 5D helps with: A normalized action envelope can expose selected context, requirements and intended-use constraints to policy.
What 5D does not establish: 5D supplies action-level inputs; it does not complete system-wide context, stakeholder or impact mapping.
Official source ↗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 ↗Gate an outbound function
from fivedrisk.hooks import gate
@gate(tool_name="send_to_api", autonomy_context=3)
async def send_payload(destination: str, payload: dict) -> None:
...Written for fivedrisk==0.7.0. Verify against the immutable source and public documentation before use.
Describe the proposed transfer
Provide the tool, normalized destination, relevant data classification, acting identity, and autonomy context. The action envelope should reflect what the tool would actually transmit, not only the agent's description of its intent.
Apply explicit red lines
Use policy rules for destinations, tools, patterns, and data classes that are not permitted together. Explicit prohibitions remain distinct from probabilistic observations about ambiguous content.
Record the blocked path
Preserve the normalized destination, rule reference, scores, disposition, and non-execution status so a reviewer can distinguish a policy block from a downstream failure.
What this page does not establish
- 5D is not a complete data-loss-prevention system and does not discover every sensitive value.
- Destination control depends on accurate extraction, normalization, and application-supplied context.
- Encrypted, indirect, or previously copied data paths may require controls outside the action gate.