One operational map across the EU AI Act, UK regulatory principles, Singapore's Agentic AI framework, NIST AI RMF, ISO/IEC 42001, and OWASP agent-security guidance.
Inspect declared red lines, identity and authority context, failure behavior, and the evidence left at the action boundary.
The records show the properties tested, the assumptions made, and the limitations that remain. The integrating organisation retains responsibility for identity, execution, outcome capture, path coverage, and any legal or assurance conclusion.
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.
This page is not legal advice. The set is intentionally bounded and is not a complete global legal inventory. Sector rules, privacy law, cybersecurity law, product safety, employment law, and contractual duties may also apply.
See which technical artifacts 5D produces across these stages ↗
The authority class matters. Law, regulator guidance, voluntary frameworks, standards, and security guidance do not create the same obligations.
Binding EU law whose obligations depend on the system, actor role, use, classification, and applicable date. The map focuses on technical evidence relevant to lifecycle risk management, logging, oversight, and robustness.
Five cross-sector principles for regulators to interpret within their remits: safety, security and robustness; transparency and explainability; fairness; accountability and governance; and contestability and redress.
Agent-specific guidance on bounding risks and powers, meaningful human accountability, technical controls across the lifecycle, and end-user responsibility.
A voluntary risk-management structure using Govern, Map, Measure, and Manage. NIST states that AI RMF 1.0 is under revision.
An organisation-wide AI management-system standard. This public mapping stays at objective level and does not reproduce or claim conformity with the normative text.
A threat and control overlay for agentic systems, not law, certification, or a complete security programme.
At every stage, the technical mechanism sits beside the responsibility that remains with the integrating organisation.
What may this agent do?
Article 9(2)(a)–(b)Identification and evaluation of known and foreseeable risks
Where 5D contributes: The action envelope can make intended actions, authority and foreseeable misuse conditions explicit as technical inputs.
Limit: 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.
Section 2 — Accountability and governanceLife-cycle accountability and governance
Where 5D contributes: Declared policy ownership and action authority can support a traceable technical control boundary.
Limit: The principles are regulator guidance applied within sector remits; the relevant regulator and organisation determine applicable duties and governance.
Dimension 1 — Assess and bound the risksBound the agent's powers and foreseeable risks
Where 5D contributes: 5D can encode action, tool, destination, data and autonomy boundaries as deterministic policy inputs.
Limit: The organisation still selects the use case, assesses impact and decides acceptable autonomy.
MAP 1.1, 1.5–1.6 and MAP 3.3Context, impacts, requirements and intended-use mapping
Where 5D contributes: A normalized action envelope can expose selected context, requirements and intended-use constraints to policy.
Limit: 5D supplies action-level inputs; it does not complete system-wide context, stakeholder or impact mapping.
Clause 6 — PlanningAI management-system planning objective
Where 5D contributes: Declared policy boundaries may serve as one inspectable technical control within an organisation's planning process.
Limit: Objective-level reference only; licensed normative text is not reproduced, and 5D does not establish ISO/IEC 42001 conformity.
Structures the proposed-action envelope and makes tools, destinations, data classes, authority, and red lines explicit.
Inspect 5D evidence ↗Use-case and legal classification, impact assessment, risk appetite, accountable ownership, and prohibited-outcome decisions.
Does the policy behave as intended?
Articles 9(7) and 15(1), 15(4)Testing, robustness and cybersecurity
Where 5D contributes: Deterministic policy tests and explicit failure states can contribute action-level testing evidence.
Limit: Only relevant where these provider duties apply; 5D scenario tests do not establish system accuracy, robustness, cybersecurity or Article 9 test sufficiency.
Dimension 3 — Implement technical controls and processesBaseline safety and reliability testing before deployment
Where 5D contributes: Scenario tests can exercise declared action policy before promotion.
Limit: Coverage is limited to the tested policy path, corpus, configuration and surrounding integration.
MEASURE 1.1–1.2; 2.1, 2.3 and 2.6–2.7Measurement approaches, test sets, performance and risk evaluation
Where 5D contributes: Release-specific deterministic tests, controlled scenarios and replay can measure a declared policy under stated conditions.
Limit: This is evidence for selected action-policy behavior, not verified satisfaction of the NIST subcategories or evaluation of the full AI system.
Clause 9 — Performance evaluationAI management-system performance-evaluation objective
Where 5D contributes: Policy test outputs may be one input to an organisation's evaluation activities.
Limit: Objective-level reference only; licensed normative text is not reproduced, and test output is not an ISO/IEC 42001 evaluation or conformity result.
ASI01 Agent Goal Hijack — mitigation 8; ASI02 Tool Misuse and Exploitation — mitigations 1–4Red-team scenarios and bounded tool-use controls
Where 5D contributes: Hostile scenarios can test one technical measure: pre-action policy on covered tool calls.
Limit: 5D does not mitigate either complete ASI risk; effectiveness depends on realistic scenarios, complete interception and host enforcement.
Supplies deterministic tests, controlled scenarios, replay, and explicit unknown or failure states for the declared action policy.
Inspect 5D evidence ↗Test sufficiency, realistic data, bypass coverage, model evaluation, acceptance criteria, independent assurance, and remediation.
Which policy and evidence are approved for use?
Articles 11(1) and 17(1)(a)–(d)Technical documentation and quality-management controls
Where 5D contributes: Versioned policy, configuration and test artifacts may support one documented change-control record.
Limit: Only relevant to applicable provider duties; 5D neither creates the complete technical documentation nor establishes a quality-management system.
Section 2 — Accountability and governanceGovernance, accountability and documented decisions
Where 5D contributes: Versioned policy artifacts can support a traceable technical approval boundary.
Limit: The relevant regulator and organisation determine governance, accountable roles, approval authority and evidence custody.
GOVERN 1.4–1.5 and 2.1–2.3Risk culture, ongoing review, roles and executive responsibility
Where 5D contributes: Policy versions and evidence hashes can make one technical approval decision reconstructable.
Limit: 5D does not assign organisational roles, establish risk culture or provide executive accountability.
Clauses 7.5 and 8.1 — Documented information; operational planning and controlDocumented-information and operational-control objectives
Where 5D contributes: Versionable policy artifacts may support controlled documented information for one runtime control.
Limit: Objective-level titles only; licensed normative text is not reproduced, and 5D does not establish management-system control or conformity.
Produces versionable policy, configuration, tests, and hashes that can support a controlled approval record.
Inspect 5D evidence ↗Approval authority, segregation of duties, exceptions, reviewer competence, release authorization, and evidence custody.
Which approved control covers each execution path?
Articles 13(2)–(3) and 26(1)–(2)Instructions for use and deployer operation and oversight
Where 5D contributes: Documented gateways and failure posture can support one technical control described for a covered action path.
Limit: Article 13 concerns provider-supplied instructions; Article 26 concerns deployers of applicable high-risk AI systems. 5D does not determine actor role, applicability, compliant use or oversight sufficiency.
Dimension 3 — Implement technical controls and processesControl access to approved tools and services
Where 5D contributes: Gateways and adapters can attach action policy to documented tool-call paths.
Limit: The host must prove complete interception, authenticate identity, secure configuration and operate the surrounding controls.
MAP 4.2 and MANAGE 3.1Component controls and third-party risk controls
Where 5D contributes: A bound gateway can implement one documented control at a selected component boundary.
Limit: 5D does not inventory components, assess third parties or prove every execution path is covered.
Clause 8.1 — Operational planning and controlOperational-control objective
Where 5D contributes: A deployed action gate may be one inspectable runtime control.
Limit: Objective-level title only; licensed normative text is not reproduced, and one gate is not an ISO/IEC 42001 operational-control system.
ASI02 Tool Misuse and Exploitation — mitigation 1; ASI03 Identity and Privilege AbuseLeast agency, tool boundaries and privilege context
Where 5D contributes: 5D can enforce one declared tool-policy boundary using caller-supplied identity and authority context.
Limit: 5D does not mitigate the complete ASI risks, authenticate identity, validate grants or guarantee complete action-path interception.
Provides gateways, hooks, and adapters that can bind policy to documented action paths.
Inspect 5D evidence ↗Identity authentication, topology, complete interception coverage, secure configuration, availability, rollback, and change management.
May this proposed action cross the boundary?
Articles 9(5)–(6), 14 and 15(1), 15(4)Risk treatment, human oversight, robustness and cybersecurity
Where 5D contributes: Pre-action prohibitions, routing and a policy-selected human hold can implement one technical risk-treatment measure.
Limit: Only relevant where these duties apply to the actor and system; 5D does not establish the wider risk system, oversight design, robustness or cybersecurity.
Dimensions 1 and 3 — Bound risks; implement technical controls and processesBound action space and enforce technical controls
Where 5D contributes: 5D can apply deterministic policy before a covered external action.
Limit: The host owns correct context, complete interception, downstream enforcement and the decision that the policy is sufficient.
MANAGE 1.2–1.3Prioritise and document risk treatment
Where 5D contributes: Permit, hold and block policy can implement one documented treatment for selected action risks.
Limit: 5D does not prioritise organisation-wide risk or determine risk acceptance and treatment sufficiency.
ASI02 Tool Misuse and Exploitation — mitigations 2 and 4Action-level approval and policy-enforcement middleware
Where 5D contributes: 5D implements one relevant measure: a pre-action policy gate with optional human approval routing.
Limit: This does not mitigate the complete ASI02 risk; it requires complete interception, trusted context and host enforcement.
Applies deterministic prohibitions and action-risk policy before the side effect. Optional observers add evidence but not permission authority.
Inspect 5D evidence ↗Correct context, authenticated identity and grants, secure interception, execution authority, downstream enforcement, and alternate-path prevention.
What happened, and can the decision be reconstructed and challenged?
Articles 12(1)–(2), 14 and 26(2), 26(5)Record-keeping, human oversight and deployer monitoring
Where 5D contributes: Action receipts and a human-review route can contribute selected technical evidence for a covered path.
Limit: Article 26 applies to deployers of applicable high-risk AI systems. 5D does not determine role or applicability, nor establish required log scope, completeness, custody, retention or oversight sufficiency.
Section 2 — Transparency and explainability; accountability and governance; contestability and redressTraceable decisions, accountability and challenge
Where 5D contributes: Reconstructable action records can support internal explanation and challenge of one policy decision.
Limit: 5D does not create affected-person notices, complaint channels, remedies, complete system explanations or regulator-specific accountability.
Dimensions 2 and 3 — Enable meaningful human accountability; implement technical controls and processesHuman checkpoints, logging and monitoring
Where 5D contributes: A policy-selected hold and action receipt can support one human checkpoint and record the resulting disposition.
Limit: The organisation owns reviewer identity, authority, competence, escalation, monitoring coverage and accountability.
MAP 3.5; MEASURE 2.4 and 3.1; MANAGE 4.1Human oversight, measurement documentation and post-deployment monitoring
Where 5D contributes: Separate policy, review and outcome states can contribute action-level evidence to oversight and monitoring.
Limit: 5D does not establish organisation-wide monitoring, assessor independence, reviewer sufficiency or incident response.
Clause 9 — Performance evaluationAI management-system performance-evaluation objective
Where 5D contributes: Action receipts may be one technical input to an organisation's monitoring and review process.
Limit: Objective-level reference only; licensed normative text is not reproduced, and receipts do not establish audit, management review or conformity.
Can hold a policy-selected action for host-owned review and preserve an action-level record with separate outcome states.
Inspect 5D evidence ↗Reviewer authority and competence, authoritative custody, completeness, retention, monitoring, incident response, notices, redress, and audit.
Should policy, integration, or agent remain in service?
Articles 9(2) and 72(1)–(3)Continuous risk management and provider post-market monitoring
Where 5D contributes: Reviewed action evidence and policy-version comparison can be inputs to reassessment and regression checks.
Limit: Article 72 is a provider obligation for applicable high-risk AI systems. 5D does not determine role or applicability and does not establish the required post-market monitoring system.
Section 2 — Safety, security and robustness; accountability and governanceContinuous life-cycle risk management and accountability
Where 5D contributes: Versioned evidence can inform a governed decision to change, suspend or retire a control.
Limit: The relevant regulator and organisation own reassessment, corrective action, decommissioning and sector-specific duties.
Dimension 3 — Implement technical controls and processesContinuous monitoring and lifecycle controls
Where 5D contributes: Replay and policy-version comparison can support controlled regression checks after change.
Limit: 5D does not decide when the agent should change or retire, operate monitoring, or manage residual data.
GOVERN 1.5, 1.7; MANAGE 2.4 and 4.1–4.3Ongoing review, decommissioning, monitoring and incident learning
Where 5D contributes: Replayable action evidence can inform controlled policy updates and regression checks.
Limit: 5D does not establish enterprise review cadence, incident management, risk acceptance or decommissioning.
Clause 10 — ImprovementAI management-system improvement objective
Where 5D contributes: Reviewed action evidence can be one input to an organisation's improvement process.
Limit: Objective-level reference only; licensed normative text is not reproduced, and 5D does not establish corrective action or continual-improvement conformity.
Replayable evidence and version comparison can inform policy change and regression checks.
Inspect 5D evidence ↗Reassessment, corrective action, reapproval, rollback, post-market monitoring, decommissioning, and residual-data handling.
Follow one illustrative attempt from proposal to a recorded outcome. This is the runtime path inside 5D, not the seven-stage governance lifecycle.
An agent proposes a consequential tool call. The host presents the action envelope to 5D before any side effect.
PROPOSED5D normalizes the tool, target, purpose, data class, identity assertion, attempt ID, and policy binding. Invalid and untrusted required input remains held.
NORMALIZED5D applies non-overridable denials first, then returns PERMIT, BLOCK, or REVIEW_REQUIRED for the normalized attempt.
REVIEW_REQUIREDA host-owned reviewer records approved, rejected, expired, or unavailable evidence. The action remains held unless declared policy resolves it to PERMIT.
EVIDENCE RECORDED5D re-evaluates the declared policy with the review evidence. Reviewer evidence informs the route; it does not independently grant permission.
PERMITHost executes only after 5D returns PERMIT. BLOCK, REVIEW_REQUIRED, malformed input, or unavailable required evidence means not attempted.
ATTEMPTEDThe host records succeeded, failed, or unknown separately from the 5D disposition; a record failed state remains explicit. Every retry creates a new attempt linked to the same logical action.
SUCCEEDEDThe decision receipt binds the action, policy, evidence, disposition, and execution outcome. Export failed or custody failure does not rewrite the decision or outcome.
RECORDEDRetry rule: Every retry creates a new attempt linked to the same logical action, so its decision and outcome remain individually reconstructable.
A runtime gate can produce useful evidence without inheriting the organisation's legal or operational accountability.
5D does not classify a system under law, assign actor roles, determine prohibited use, or decide whether an obligation applies.
5D does not create accountable ownership, reviewer competence, impact assessment, management review, redress, or risk acceptance.
5D does not prove integration coverage, authenticate identity, secure credentials, execute recovery, or make an agentic system safe by itself.