Forem: Fuzentry™

# Pre-Execution Gates: How to Block Before You Execute (Part 2/3)

Fuzentry™ — Wed, 22 Apr 2026 18:15:00 +0000

This is Part 2 of a three-part series on AI governance architecture. In Part 1, we explored why signed receipts can't solve the negative proof problem—the challenge of proving that unauthorized actions didn't happen. Today, we'll examine the architectural pattern that does solve it: pre-execution gates that evaluate governance policy before any AI execution occurs.

Note: This series explores architectural patterns for AI governance based on regulatory requirements and cryptographic best practices. Code examples are simplified illustrations for educational purposes, not production implementations. The patterns discussed apply broadly across different tech stacks and deployment environments.

In Part 1, we established that receipt-based governance systems face a fundamental limitation. They're excellent at proving what happened, but they cannot prove what didn't happen. When HIPAA requires that you prevent unauthorized PHI access, or when PCI DSS mandates preventing cardholder data access beyond need-to-know, receipts showing proper access don't address the core requirement. The regulation isn't asking for detection—it's demanding prevention.

The architectural pattern that solves this problem is conceptually straightforward but requires rethinking where governance evaluation occurs in your AI request flow. Instead of logging decisions after execution completes, you evaluate governance policy before execution begins. The AI request cannot proceed until that evaluation completes. If the policy says DENY, execution is blocked. The model never gets called, the tool never gets invoked, the data never gets accessed.

This might sound like a small change in sequencing, but it creates a fundamentally different kind of evidence artifact. Instead of a receipt proving "here's what happened," you get a denial proof demonstrating "here's what was prevented from happening." That distinction is what makes negative proofs possible.

Understanding the Timeline Difference

The clearest way to see why this matters is to compare the execution timelines side by side. Let's start with how a receipt-based system handles a request.

In a receipt-based architecture, the sequence looks like this. First, your request arrives at the AI system's entry point. Maybe that's an API endpoint, maybe it's a message queue, maybe it's a function call inside your application code. Wherever it enters, the system immediately begins processing it. The AI model gets invoked with the request payload. The model generates a response based on its training and the input it received. Your application processes that response and potentially takes actions based on it—updating a database, calling external APIs, returning results to a user. Only after all of that execution completes does the governance layer get involved. It creates a receipt documenting what just happened. That receipt gets signed cryptographically to prevent tampering, then stored in your audit log for future review.

Notice what this means: execution happened first, then governance was applied. The system evaluated "did this request follow policy?" after the request had already completed. If the answer turns out to be no, you have a receipt documenting the policy violation, but the violation itself already occurred. The unauthorized data access already happened, the prohibited action already executed, the boundary already got crossed.

Now let's look at a pre-execution gate architecture. The request still arrives at your system's entry point, but what happens next is different. Before any execution occurs, before the AI model gets called, before any tools get invoked, the request passes through a governance evaluation layer. This layer loads the policy that applies to this request—which might be tenant-specific, folder-specific, or role-specific depending on your system design. It evaluates whether the request should be allowed based on that policy. If the policy returns ALLOW, execution proceeds normally and the system generates a receipt just like the receipt-based architecture would. But if the policy returns DENY, something different happens: execution is blocked entirely. The model call never happens, the tool invocation never occurs, the data access is prevented. Instead of a receipt for a completed action, the system generates a denial proof showing that the governance layer blocked an unauthorized request.

The critical architectural difference is in what can happen after the policy evaluation. In a receipt-based system, execution already occurred, so a DENY decision is just creating documentation of a violation. In a gate-based system, execution hasn't happened yet, so a DENY decision actually prevents the violation from occurring. That's the shift from detection to prevention.

What This Looks Like in Code

Let's make this concrete with a simplified implementation. Here's what a pre-execution gate looks like in a serverless AI architecture running on AWS Lambda and Bedrock. The specifics of the cloud platform don't matter much—the pattern works equally well on other infrastructure. What matters is the sequence of operations and where governance evaluation occurs relative to execution.

async def handle_ai_request(request, context):
    """
    ExecutionRouter - this runs BEFORE any AI execution.
    Every AI request passes through here with no bypass paths.
    """

    # Step 1: Authenticate the caller
    # We need to know who's making this request before we can evaluate
    # whether they're allowed to do what they're asking for
    caller_identity = validate_jwt(request.headers['Authorization'])

    # Step 2: Resolve tenant and folder context
    # Governance policies are scoped to organizational boundaries,
    # so we need to know which tenant and folder this request belongs to
    tenant_id = caller_identity.tenant_id
    folder_id = request.body.get('folder_id')

    # Step 3: Load the governing policy
    # Policies are versioned immutably so we can prove which rules
    # were in effect when decisions were made
    policy = get_policy(tenant_id, folder_id)

    # Step 4: Evaluate request against policy BEFORE execution
    # This is the pre-execution gate - nothing proceeds until this completes
    decision = evaluate_policy(
        request=request.body,
        policy=policy,
        caller=caller_identity
    )

    # Step 5a: If DENY, block execution and generate denial proof
    # Note that invoke_bedrock_model is never called in this branch
    if decision.verdict == 'DENY':
        # Create proof showing what was prevented
        denial_proof = generate_denial_proof(
            request_hash=hash_request(request.body),
            policy_version=policy.version_hash,
            rule_fired=decision.rule_id,
            timestamp=utcnow(),
            reason=decision.reason
        )

        # Sign with KMS to make tampering detectable
        signed_proof = kms_sign(denial_proof)

        # Store in audit ledger for compliance queries
        store_denial(signed_proof)

        # Return 403 with the signed proof
        # The caller gets evidence that governance prevented their request
        return {
            'statusCode': 403,
            'body': {
                'error': 'Governance policy denied this request',
                'denial_proof': signed_proof,
                'reason': decision.reason
            }
        }

    # Step 5b: If ALLOW, now we can proceed with execution
    # This is the only code path that reaches the model
    result = await invoke_bedrock_model(request.body)

    # Step 6: Generate receipt for allowed execution
    # This works just like receipt-based systems for allowed requests
    receipt = generate_receipt(
        request=request.body,
        response=result,
        policy_version=policy.version_hash,
        timestamp=utcnow()
    )

    signed_receipt = kms_sign(receipt)
    store_receipt(signed_receipt)

    return {
        'statusCode': 200,
        'body': result,
        'headers': {
            'X-Governance-Receipt': signed_receipt.id
        }
    }

The key architectural constraint is that model execution must be unreachable if policy evaluation returns DENY. How you enforce this depends on your infrastructure—it might be IAM policies preventing direct model API access, network segmentation that requires routing through the governance layer, or application-level controls that make the execution path conditional on policy decisions. The critical requirement is that there's no code path, no bypass route, and no error handler that circumvents the gate.

In cloud environments, this typically means using your platform's access control systems to enforce the constraint. Even if a developer tried to call the model directly from elsewhere in your codebase, the infrastructure access policies would prevent it because model APIs are only accessible through the governance router.

This structural enforcement is fundamentally different from adding logging to an existing execution flow. Many organizations start with a working AI system, then add governance by wrapping function calls in logging statements. That approach creates receipts but doesn't create gates. The gates pattern requires that governance evaluation be mandatory and blocking, not optional and observational.

Why Determinism Becomes Essential

Once you implement pre-execution gates, you inherit a new requirement that receipt-based systems can often ignore: your policy evaluation must be deterministic. If you evaluate the same request against the same policy twice, you must get the same decision both times. No randomness, no time-dependent logic that might produce different results on different days, no external API calls that might return different data.

This matters because deterministic evaluation enables replay verification, which is how you prove to an auditor that a denial actually happened and wasn't fabricated. The verification process works like this.

An auditor pulls up one of your denial proofs and wants to verify its authenticity. They start by retrieving the policy version that was in effect when the denial occurred. Your system stored that policy immutably, so they get exactly the same policy document that was used for the original decision. Next, they retrieve the original request, or at least a hash of it that's included in the denial proof. Then comes the crucial step: they re-run the policy evaluation using the original request and the original policy. If your policy engine is deterministic, this replay evaluation must produce the same DENY decision with the same reason code.

If the replay produces a different decision, something is wrong. Either the policy was mutated after the fact, which should be impossible if you're versioning policies immutably, or the governance engine itself is non-deterministic, which means you can't trust any of its decisions. The determinism requirement is what makes denial proofs verifiable and therefore trustworthy.

Receipt-based systems can often get away with non-deterministic logging because they're just documenting what happened, not making enforce-or-allow decisions that need to be reproducible. But once you're blocking execution based on policy evaluation, reproducibility becomes mandatory. An auditor needs to be able to confirm that the policy would still produce a DENY decision if evaluated again with the same inputs.

Here's what a deterministic policy evaluation looks like for the cross-patient PHI access scenario from Part 1:

def evaluate_folder_isolation_policy(request, policy):
    """
    Deterministic evaluation - same request + same policy = same decision.
    No external API calls, no time-dependent logic, no random values.
    """

    # Extract request context
    source_folder = request.folder_id
    target_folder = request.target_folder_id
    data_classification = request.target_data_class

    # Load policy rule (from the policy document, not external system)
    rule = policy.get_rule('prevent_cross_folder_phi_access')

    # Evaluate deterministically
    if source_folder != target_folder and data_classification == 'PHI':
        return Decision(
            verdict='DENY',
            rule_id=rule.id,
            reason=f"Cross-folder PHI access denied per {rule.regulatory_basis}",
            policy_version=policy.version_hash
        )

    return Decision(verdict='ALLOW')

Notice what this policy doesn't do. It doesn't call an external API to check whether cross-folder access is allowed. It doesn't query a database to see if there's an active sharing relationship. It doesn't check the current time to see if we're in an allowed time window. All of those patterns would make the policy evaluation non-deterministic, which would break replay verification. Instead, the policy rule is self-contained: it examines the request itself and makes a decision based solely on the data in that request and the rules in the policy document.

This doesn't mean you can't have sophisticated governance logic. You can absolutely have complex rules that consider many factors. But those factors need to come from the request context or from the policy document itself, not from external state that might change between the original evaluation and a replay verification.

Solving the Performance Problem

The obvious concern with pre-execution gates is latency. If every AI request has to pass through a policy evaluation layer before execution can begin, doesn't that add overhead that might be unacceptable for latency-sensitive applications?

Yes, it does add overhead. That's not something to handwave away—it's a real tradeoff that you need to account for in your architecture. But the overhead is manageable if you design your policy evaluation with performance in mind.

The pattern that works well in practice is fast-path synchronous evaluation with async fallback. You try to evaluate the policy synchronously with a tight timeout, typically 50 milliseconds or less. Most governance rules are simple enough that they evaluate in single-digit milliseconds: folder isolation checks, budget verifications, PII masking rules. These run fast because they're just comparing values from the request against thresholds or patterns defined in the policy.

If the fast-path evaluation completes within your timeout, you get a decision immediately and execution proceeds with minimal added latency. But if the policy evaluation times out—maybe because the policy is complex, maybe because it requires some expensive computation—you fall back to async evaluation. The system enqueues the evaluation as a background job, returns a provisional ALLOW to let execution proceed, but flags the result for review.

Here's what that looks like in code:

async def evaluate_policy_with_fallback(request, policy, caller):
    """
    Try fast synchronous evaluation first, fall back to async if needed.
    Most requests take the fast path. Complex policies hit async fallback.
    """

    try:
        # Fast path: evaluate with 50ms timeout
        # This handles 95%+ of requests in production
        decision = await evaluate_policy_fast(
            request=request,
            policy=policy,
            timeout_ms=50
        )
        return decision

    except TimeoutError:
        # Fast path timed out, use async fallback
        # This is rare but necessary for complex policies
        job_id = enqueue_async_evaluation(request, policy)

        # Return provisional ALLOW so execution isn't blocked
        # But flag this for later review when async eval completes
        return Decision(
            verdict='ALLOW',
            provisional=True,
            async_job_id=job_id,
            reason='Policy evaluation delegated to async worker'
        )

The async fallback pattern means you're not blocking execution indefinitely waiting for slow policy evaluations to complete. But you're also not just giving up on governance for complex policies. If the async evaluation later returns DENY, that gets surfaced as a compliance alert that your security team can investigate. This is still better than having no gate at all, because the decision is being evaluated and logged even if it can't enforce in real time.

Many organizations run both patterns in parallel during initial rollout to reduce risk. They start with observer mode on all surfaces: the gate evaluates policy but always returns ALLOW, so nothing gets blocked while they validate that policy rules are working correctly. Denials are logged with full denial proofs, but execution proceeds. This lets you build confidence in your policies without risking production breakage.

Once you've validated that observer mode is working well, you enable enforcer mode selectively. Typically organizations start with high-risk surfaces like data export and cross-tenant access where the blast radius of blocking something incorrectly is manageable and the security benefit of enforcement is high. Lower-risk surfaces like model selection or tool invocation might stay in observer mode longer while you refine the policies.

What We've Established

At this point, we've covered the core concepts of pre-execution gates: they evaluate policy before execution rather than after, they create denial proofs rather than just violation receipts, they require deterministic policy evaluation to enable replay verification, and they can be implemented with acceptable performance overhead using fast-path evaluation and async fallback.

What we haven't covered yet is how to actually build a complete pre-execution gate system in production. That's what Part 3 will tackle: a layered reference architecture that shows you exactly which components you need, how they fit together, what each layer is responsible for, and when you can get away with simpler receipt-based systems versus when pre-execution gates become mandatory.

We'll also explore the policy design principles that make gates practical to operate. Not every governance rule belongs in a pre-execution gate. Some controls are better implemented as detective measures that analyze patterns over time. Figuring out which goes where is part of building a governance architecture that's both secure and operationally sustainable.

Read Part 1: The Negative Proof Problem in AI Governance

Read Part 3: Building a Production-Ready AI Governance Stack [coming soon]

The Negative Proof Problem in AI Governance (Part 1/3)

Fuzentry™ — Tue, 21 Apr 2026 12:27:00 +0000

This is Part 1 of a three-part series exploring why post-execution receipts aren't sufficient for AI governance in regulated environments, and what architectural patterns solve this gap. In this first installment, we'll examine what receipts do well, where they fall short, and why proving something didn't happen is fundamentally different from proving something did happen.

Note: This series explores architectural patterns for AI governance based on regulatory requirements and engineering best practices. The concepts discussed apply broadly to AI systems operating under compliance frameworks that require prevention capabilities.

The AI governance conversation has been dominated by a single architectural pattern: generate receipts after the fact. Modern governance tools produce audit logs, attestations, and cryptographically signed artifacts that prove what an AI system did. When your model makes a decision, routes a customer request, or accesses sensitive data, these tools create a permanent record showing exactly what happened and when it happened.

On the surface, this approach seems comprehensive. If you can cryptographically prove that a decision was made under a specific policy version, complete with timestamps and tamper-evident signatures, what more could an auditor possibly need? The answer becomes clear when you shift from asking "what did the system do?" to asking a different question entirely: "how do you prove something didn't happen?"

This seemingly simple question reveals a fundamental architectural gap between observability-first governance systems and enforcement-first governance systems. Most of the AI governance tooling landscape focuses squarely on the former, building increasingly sophisticated ways to track and verify what AI systems have done. Only a handful of systems implement the latter, creating mechanisms to prevent unauthorized actions before they can occur. Understanding why this distinction matters requires stepping back from the implementation details and examining what governance actually means when regulators get involved.

What Signed Receipts Do Well

Before we explore their limitations, it's worth acknowledging what signed receipts solve effectively. Imagine you're operating an AI-powered customer support system that processes sensitive customer information throughout the day. Every time your AI agent makes a decision—routing a support ticket, suggesting a refund amount, accessing account details to answer a question—your governance system generates a receipt that captures the complete context of that decision.

That receipt typically includes several key pieces of information. First, there's the input that went into the AI model, which might be sanitized or redacted depending on how sensitive the data is. Next, you have the policy that was governing the system at that moment, complete with version information so you can track exactly which rules were in effect. Then comes the output the model produced, along with any actions the system took based on that output. Finally, the entire receipt gets wrapped in a cryptographic signature that makes tampering detectable.

When your compliance officer sits down with an external auditor and faces questions about what happened on a particular day, you can hand over a complete set of these signed receipts. The auditor can verify the cryptographic signatures to confirm the receipts haven't been altered since they were created. They can review the policy versions to validate that your controls were consistently applied. They can trace the audit trail to demonstrate that your governance system was functioning as designed.

For many compliance requirements, particularly those focused on demonstrating that controls exist and operate consistently, this receipt-based approach works remarkably well. SOC 2 audits, for example, primarily care about showing that you have documented policies, that those policies are actually implemented in your systems, and that you can prove they ran as designed. Signed receipts provide exactly that kind of evidence. The receipts show your policies in action, demonstrate consistency over time, and provide the cryptographic proof that auditors need to trust the integrity of your records.

The architectural elegance of this approach becomes even more apparent when you consider scalability. Modern receipt-based systems batch individual receipts into Merkle tree structures, creating hierarchical hashes that let you verify thousands of receipts by checking a single root hash. Those root hashes can be anchored to immutable storage systems, whether that's blockchain-based ledgers or cloud storage with write-once-read-many guarantees. This design means auditors can validate your entire governance posture without needing access to your production infrastructure, your live databases, or your running systems. They get the verification they need while your operational security remains intact.

But there's a category of regulatory requirements where receipts fundamentally cannot provide the evidence that auditors demand.

The Healthcare Scenario: When Prevention Becomes Mandatory

Let's make this concrete with a scenario from healthcare AI, where the gap becomes immediately visible. You're operating an AI system that helps clinical staff manage patient records across a hospital system. Your AI agents can read patient data, suggest treatment adjustments, flag potential drug interactions, and route information between different departments. To comply with HIPAA regulations, you've implemented strict controls to ensure that patient health information remains private and is only accessible to authorized personnel working with specific patients.

Here's where things get interesting. An AI agent that's been assigned to help manage Patient A's care let's say this agent is bound to the intensive care unit and has legitimate access to ICU patient records attempts to read medical information from Patient B's folder. Patient B happens to be in the cardiology unit, which is a completely separate partition of your patient data system. This cross-patient access attempt represents exactly the kind of unauthorized PHI access that HIPAA exists to prevent.

Notice the verb in that last sentence. The regulation doesn't say "detect and report unauthorized access." It doesn't say "log and alert when unauthorized access occurs." It says prevent unauthorized access. The regulatory text is explicit: you must implement technical safeguards that prevent unauthorized access to protected health information, as stated in 45 CFR Section 164.312(a)(1).

If you're using a receipt-based governance system, you've just encountered an insurmountable problem. Your system is fundamentally designed to create records of what happened. It logs the agent's access to Patient A's data. It generates receipts showing that Policy Version 2.4 was in effect. It proves through cryptographic signatures that those records are authentic and unaltered. But when the auditor asks the question that actually matters—"did Agent A ever access Patient B's data?"—your receipt system cannot provide the answer they need.

You can show them receipts proving that Agent A correctly accessed Patient A's data a thousand times. You can demonstrate that your policies were consistently evaluated. You can provide cryptographic proof that your audit trail is intact. But the absence of a receipt for unauthorized access doesn't prove that the unauthorized access never happened. It could mean the access attempt was prevented by your controls, which is good. It could mean the access happened but no receipt was generated because the logging failed, which is bad. It could mean a receipt existed at one point but was deleted, which is worse. It could mean the access bypassed your governance system entirely, which is catastrophic.

This is what we call the negative proof problem. Receipts tell you what happened. They fundamentally cannot prove what didn't happen. The absence of evidence is not evidence of absence, as the saying goes, and that philosophical principle becomes a concrete compliance blocker when regulations mandate prevention rather than detection.

The Language of Prevention Across Regulatory Frameworks

The healthcare scenario isn't an edge case. Once you start looking for prevention language in regulatory frameworks, you find it everywhere. These requirements create negative proof obligations that receipt-based systems simply cannot satisfy.

In healthcare, HIPAA's access control requirements use prevention language throughout. The regulation mandates that you prevent unauthorized access to electronic protected health information. It requires technical safeguards that prevent access attempts beyond what someone's role legitimately requires. When a HIPAA auditor examines your AI systems, they're not primarily interested in your ability to detect violations after they happen. They want to understand how you prevented those violations from happening in the first place.

The financial services sector has similar requirements. PCI DSS Requirement 7 states that you must prevent cardholder data access beyond business need-to-know. Not "log when it happens," not "alert on suspicious patterns," but prevent it from happening at all. When your acquiring bank conducts a compliance assessment, they need evidence that your controls actively blocked unauthorized access attempts, not just records showing that authorized access was properly logged.

Banking regulators have encoded prevention requirements into model risk management guidance. SR 11-7, the Federal Reserve's supervisory guidance on model risk management, requires that financial institutions prevent their AI models from accessing data sources beyond what's been explicitly authorized for model inputs. Section 4.3 on data governance makes it clear that model input controls should block unauthorized data access, not merely detect it after the fact.

Even the newer European regulations follow this pattern. GDPR Article 5(1)(b) requires that personal data processing be limited to the purposes for which it was collected, and the technical implementation of that requirement means preventing processing beyond those original purposes. When a data protection authority conducts an assessment, they expect to see technical controls that enforce purpose limitation, not just audit logs showing what purposes were used.

The common thread across all these frameworks is that compliance requires demonstrating prevention capability, not just detection capability. Receipt-based systems excel at the latter but fail at the former. That's not a shortcoming of any particular implementation—it's a fundamental characteristic of the architectural pattern itself.

Why This Matters Beyond Compliance

You might reasonably wonder whether this negative proof problem is just a compliance technicality, something that matters to auditors but doesn't affect real-world system reliability or security. The answer is no, and understanding why requires thinking about what happens when governance systems fail.

Consider what a receipt-based system looks like when something goes wrong. Your AI agent makes an unauthorized cross-tenant data access. Maybe it's a policy bug, maybe it's a misconfigured permission, maybe it's an agent that's been compromised somehow. If your governance system is receipt-based, here's what happens: the unauthorized access succeeds, data gets read or modified that shouldn't have been touched, and your system dutifully generates a receipt documenting what happened. You might catch it in your next audit log review. You might get an alert if your monitoring system flags the pattern as anomalous. But the damage is already done. The data was accessed, the privacy boundary was crossed, the regulatory violation occurred.

Now consider the same scenario with a prevention-first system. The AI agent attempts the unauthorized cross-tenant access. Before that access can complete, the request passes through a governance evaluation layer that checks whether the access is permitted. The policy says no, this agent isn't authorized to access data outside its assigned tenant boundary. The governance layer blocks the request before any data access occurs. The model never gets called, the data never gets read, the privacy boundary holds. The system generates a record of what was prevented, not what was allowed to happen.

The difference isn't just about compliance elegance or audit aesthetics. It's about the actual security posture of your AI systems. Prevention-first architectures reduce the blast radius of failures. They ensure that policy violations don't result in actual data exposure. They create what security engineers call defense in depth—multiple layers of protection where even if one layer fails, others are still enforcing controls.

What Comes Next

In Part 2 of this series, we'll explore the architectural pattern that solves the negative proof problem: pre-execution gates. These are governance primitives that evaluate policy before any AI execution occurs, creating a mandatory checkpoint that requests cannot bypass. We'll examine how they work at a technical level, what they look like in code, and why deterministic policy evaluation becomes essential once you implement pre-execution controls.

For now, the key insight to take away is this: if your compliance requirements include prevention language, if you operate in regulated verticals where negative proofs matter, or if you're building AI systems where unauthorized actions create meaningful risk, receipt-based governance isn't sufficient. You need an architectural pattern that can demonstrate not just what your system did, but what it was prevented from doing.

The good news is that building prevention-first governance doesn't require throwing away everything you've built with receipt-based systems. The two patterns complement each other. Receipts remain essential for demonstrating that allowed actions followed the right policies. Pre-execution gates add the prevention layer that receipts cannot provide. Together, they create a complete governance stack that satisfies both the "show me what happened" questions and the "prove it didn't happen" questions.

We'll dive into exactly how to build that complete stack in the next installment.

Read Part 2: Pre-Execution Gates: How to Block Before You Execute [coming soon]