An agent can choose the right tool and still use it with the wrong permissions. A retriever can find a relevant document that the current user should never receive. These are authorization problems, and a system prompt cannot enforce the boundary on its own.
The useful architecture is a policy check at each protected operation: before a tool runs, before a data query crosses an access boundary, and before retrieved content reaches a model. The application must make the decision effective by blocking, narrowing, or escalating the operation.
Start with the framework’s actual controls
AI frameworks already provide useful safeguards. LangChain, for example, documents PII middleware and human approval for tool calls. It would be inaccurate to say that all frameworks lack mitigations.
The deployment still has to connect those controls to its own identity system, permitted purposes, data classifications, and storage boundaries. Redacting an email address does not establish whether an advisor may read a particular student record. A human approval hook also needs an approval policy, a reviewer, and a path that resumes only the approved operation.
Use framework hooks where they fit. Put the authorization rule in shared application code so another agent, scheduled job, or direct API route cannot bypass it.
Separate the boundaries
A protected RAG workflow has several distinct operations:
Verified identity and server-side authorization scope
→ scoped data-store query
→ retrieved-document validation
→ permitted context assembly
→ model request
→ response checks and authorized delivery
A query-time constraint reduces what the data store returns. A post-retrieval filter checks documents that have already reached the application. A response filter checks generated output after inference. Each has a role; they protect different boundaries.
For example, a filter placed between a Haystack retriever and a prompt builder can prevent excluded documents from reaching that prompt builder. It cannot establish that the retriever never read them. Likewise, removing text from a response cannot undo an earlier transfer to a model provider.
Whether a particular transfer is legally permitted depends on the parties, purpose, authorization, and applicable rules. The fact that a document was ranked internally does not, by itself, establish an unlawful disclosure.
Turn policy decisions into execution controls
Here is a small synchronous example using regulated-ai-governance. It was checked against source revision 8d999b8, whose package metadata is 0.46.0. This is a source-version reference, not a claim that this version is available on PyPI. To use that exact revision:
python -m pip install "regulated-ai-governance @ git+https://github.com/ashutoshrana/regulated-ai-governance.git@8d999b8a4bef8aa5663e792c03bf8b7b7bf8d151"
from regulated_ai_governance import ActionPolicy, GovernedActionGuard
# Demonstration only: replace this collector with an acknowledged durable sink.
events = []
guard = GovernedActionGuard(
policy=ActionPolicy(allowed_actions={"read_academic_record"}),
regulation="FERPA",
actor_id="demo-advisor", # Production: verified server-side identity.
audit_sink=events.append,
require_audit=True,
audit_execution=True,
block_on_escalation=True,
raise_on_deny=True,
)
result = guard.guard(
action_name="read_academic_record",
execute_fn=lambda: {"status": "synthetic example"},
)
assert result["status"] == "synthetic example"
assert len(events) == 2 # Decision and execution outcome.
This checks an action name and wraps its execution. It does not authenticate the actor or authorize a particular database row. The protected tool must also enforce its institution, subject, and purpose scope using trusted server-side values. An action called read_academic_record is not permission to read every academic record.
In the reviewed implementation, an audit sink failure before execution blocks the call. If outcome logging fails after the operation, the operation has already happened; an AuditDeliveryError reports that distinction. Retrying a write without checking its outcome can duplicate it.
require_audit=True rejects a missing sink, but cannot prove that a sink’s acknowledgment means durable storage. Delivery, retention, access controls, and recovery remain the deployment’s responsibility. An in-memory list only demonstrates the interface.
Make failure behavior explicit
Treat a missing identity, missing policy scope, or malformed private-record metadata as a blocking condition. Keep public content in a trusted classification path; missing metadata is not evidence that content is public.
Check configuration as well as code. An empty ActionPolicy.allowed_actions is permissive in the reviewed implementation, so production configuration must reject an accidentally empty allowlist. Advisory or audit-only modes do not block execution. Escalation must stop the operation if approval is required, and every protected route must actually invoke the guard.
Keep legal claims narrower than software claims
The rules differ by regime and use case. The official guidance below was accessed on November 1, 2026; it is not a reconstruction of what each page said in April or October:
- FERPA: The school-official exception includes legitimate educational interest and conditions for outsourced parties. Institutions must use reasonable access-control methods. A filter does not establish the exception’s conditions. See 34 CFR § 99.31(a)(1).
- HIPAA: The current Security Rule addresses safeguards for ePHI. HHS separately describes its proposed cybersecurity changes; a proposal should not be presented as an active requirement. The current-rule summary and proposal page distinguish them. The minimum-necessary standard also has exceptions, including certain treatment disclosures.
- EU AI Act: Classification and obligations depend on the system’s intended use and the organization’s role. A sector label alone does not settle scope. Use the Commission’s current implementation guidance rather than one deadline for all high-risk systems.
A decision record supports review; its format is not a legal certification. FERPA recordkeeping has exceptions under § 99.32(d). HIPAA accounting and GDPR processing records require their own analysis. A regulation label or an is_compliant field cannot make these obligations interchangeable.
Connect the control to evidence
Map each protected data flow: source, retriever, reranker, model provider, tool, cache, and audit destination. For each boundary, record the required control, the enforcing code path, the approved configuration, and the test or observed result that demonstrates it. Keep unresolved gaps visible; documenting a control is not the same as operating it.
Bind runtime records to the deployed code revision and policy/configuration version. Then check both questions: did the guard run on the relevant route, and did its implementation make the intended decision? An allow decision from a defective category matcher is still a defective decision even when the log is complete.
Protect the audit trail against unauthorized changes and deletion. Hash chaining can help detect changes relative to a trusted checkpoint, but an operator who can replace the entire chain can recompute it. Protect checkpoints or use independently held anchors, and control signing keys and storage access. Tamper evidence does not prove that the original decision was correct or that every event was recorded. OWASP’s logging guidance covers log protection and tamper detection.
Test the operation that must remain blocked
Use synthetic records to verify denied actions, wrong institutions, missing identities, malformed metadata, attempted bypasses, and audit failures. Assert that a blocked tool was never called and that excluded text never reaches the model-request payload. Test approved paths too, so the controls do not silently disable the intended workflow.
The regulated-ai-governance, enterprise-rag-patterns, and haystack-ferpa-filter projects provide examples of these programmatic controls. Their checks support a governed application; deployment evidence and the organization’s legal assessment determine what the application can claim.
Top comments (3)
The enforcement-layer pattern (regulatory rule engine, structured audit, HITL checkpoints) solves policy. The gap that surfaces during real audits: proving those records weren't retroactively edited. Append-only databases help, but the auditor still trusts the database operator. Hash chains where each record includes the previous record's hash give tamper-evidence without trusting any single infrastructure owner. Especially relevant for multi-agent workflows where the orchestrator, the model provider, and the compliance layer are operated by different parties and nobody wants to be the single point of trust.
Solid architectural framing. The pre-execution governance layer pattern is the right structural answer to the problem you have described, and the point about unauthorised access occurring during retrieval rather than in the output is one that most teams implementing AI in regulated environments genuinely do not understand until someone explains it clearly.
I want to raise a question that the architecture does not address, because I think it is the next layer of the same problem.
The governance layer you have described correctly enforces access control at runtime. But there is a prior question that sits underneath it: how do you know the governance layer itself is correctly implemented in the codebase?
Consider the HIPAA adapter. The policy declares phi_categories, sets minimum_necessary to True, and references 45 CFR § 164.502(b). The structured audit record then states "Access authorised minimum necessary standard applied." That record is accurate only if the enforcement logic in the filter actually applies the minimum necessary standard correctly to the specific data retrieved in that specific context. If there is a bug in the phi_categories matching logic, or if the integration passes the wrong role to the authorisation check, or if a developer subsequently modified the filter behaviour without updating the policy configuration, the audit trail will confidently record compliant decisions that were not compliant.
The compliance claim rests on two separate questions, not one. The first is: does the runtime governance layer fire on every relevant action? That is what this architecture solves. The second is: does the implementation of the governance layer do what it was designed to do? That is a codebase audit question, not a runtime enforcement question.
This matters because regulators do not accept "we had a governance library installed" as evidence of compliance. They ask for evidence that the specific controls required by the regulation were correctly implemented and consistently applied. A structured audit trail that was produced by a buggy filter is not compliant evidence it is a confidence-inducing record of non-compliant decisions.
On the ArkForge point about hash chains and tamper evidence the observation is technically correct and the problem is real. But I think there is a further layer to it. Hash chains prove that the audit record was not edited after it was written. They do not prove that the governance decision reflected in the record was correct at the time it was made. The authoritative source of what the governance layer was supposed to do lives in the codebase and the policy configuration, not in the audit trail. Proving the trail is tamper-evident is meaningful only if you can also prove the decisions that produced the trail were correct.
For multi-party agentic deployments specifically, where the orchestrator, the model provider, and the compliance layer are operated by different parties as the ArkForge comment notes, this creates an interesting verification problem. Each party can prove their own audit trail is tamper-evident. None of them can independently prove that the other parties' governance layers were correctly implemented. That requires a form of cross-party codebase verification that does not currently have a standardised approach.
The regulatory trajectory suggests this will become a formal requirement before long. GDPR Article 25 (data protection by design and by default) already implies it. The EU AI Act's conformity assessment obligations for high-risk systems are moving toward it. The question of how you prove the implementation matches the designed governance architecture, not just that a governance layer exists, is the audit question that comes after the one your article addresses.
For teams deploying high-risk AI under EU jurisdiction, meeting compliance deadlines requires immediate action rather than waiting for full remediation.
A practical compliance path starts with three essential steps:
Engaging a third-party audit early creates an indispensable evidence trail for regulatory scrutiny, giving teams a solid posture even while longer-term remediations remain ongoing.