# Silent Drift: How LLMs Are Quietly Breaking Organizational Access Control


The promise of large language models in security is compelling: automate policy writing, accelerate compliance workflows, and reduce human error in critical infrastructure code. Yet a concerning vulnerability in this approach is emerging—one that operates silently, bypassing traditional security reviews and fundamentally compromising organizational access control models.


LLMs excel at generating complex policy-as-code in seconds. But each generated line carries hidden risk: a single missing condition, a hallucinated attribute, or a subtle logic error can dismantle your organization's carefully constructed least-privilege security posture without triggering a single alert.


## The Threat: Silent Drift in Access Control


The core issue is deceptively simple but strategically dangerous. Modern access control frameworks like Rego (used by Open Policy Agent) and Cedar (AWS's policy language) require precise, condition-aware logic. A policy that *appears* to restrict access—and reads correctly at first glance—might inadvertently grant permissions through logical gaps or fabricated attributes that exist nowhere in your system.


Consider a practical example: an LLM generates a Rego policy intended to restrict API access to specific roles:


allow_api_access if {
    input.user.role == "admin"
    input.request.action == "read"
}

This looks reasonable until a security engineer discovers the LLM hallucinated the input.request.action attribute—your API never actually sends that field. The condition silently fails to evaluate, effectively allowing all requests through. The policy fails open rather than closed, a catastrophic outcome in access control.


This is "silent drift": the gradual, undetected degradation of security posture through policy code that compiles, deploys, and executes without errors—yet doesn't enforce what it claims to enforce.


## Background and Context


Organizations increasingly rely on policy-as-code to manage access control at scale. Instead of hardcoding authorization logic in applications, teams define policies separately and version them alongside infrastructure. This separation offers genuine benefits:


  • Consistency: Policies apply uniformly across systems
  • Auditability: Policy changes are tracked and reviewable
  • Flexibility: Updates don't require application redeployment

    • The natural next step, then, is automation. Why manually write complex Rego or Cedar policies when LLMs can generate them from English descriptions? The time savings are real—generating a policy takes seconds versus hours of manual engineering.


    But this efficiency introduces a critical vulnerability: LLMs generate code that reads fluently but may not execute as intended.


    Unlike traditional code generation for applications, where syntax errors are caught by compilers and logic errors surface through testing, policy-as-code has a lower bar for visibility:

  • Policies compile successfully even with logical flaws
  • The absence of a policy denial is often indistinguishable from a policy grant
  • Errors may only surface when an unauthorized request succeeds—sometimes weeks or months later

    • ## Technical Details: How Silent Drift Occurs


    ### Hallucinated Attributes


    LLMs frequently invent attributes, fields, or data structures that align with reasonable naming conventions but don't actually exist in your system. In Rego or Cedar policies, referencing non-existent attributes causes the condition to fail or evaluate unexpectedly.


    Example scenario:

    Your organization uses a SAML identity provider that sends attributes department, clearance_level, and team. An LLM generates a policy restricting sensitive data access to users with security_clearance == "level_3". The attribute name is plausible—but your IdP actually sends clearance_level. The policy silently grants access to everyone because the condition never evaluates.


    ### Missing Conditions


    LLMs optimize for brevity and readability. When generating policies, they may omit edge cases or fail-safe conditions that human engineers would include.


    Example:

    A policy intended to allow administrative actions only during business hours might omit a time-zone normalization step, allowing an attacker to exploit time-zone differences to bypass the restriction.


    ### Logic Inversions


    Pattern-matching on policy language can lead to subtle inversions:


    # Intended: deny if not authenticated
# Generated: allow if authenticated (subtle but different)

    The LLM's confidence in fluent, human-readable syntax can mask logical inversions that would fail rigorous review.


    ## Implications for Organizations


    ### Compliance and Audit Risk


    Policies generated by LLMs may pass surface-level audits—they're documented, version-controlled, and appear comprehensive—while silently violating the principle of least privilege. Auditors scanning policy text may miss logical flaws that require deep technical analysis.


    Organizations subject to SOC 2, ISO 27001, or industry-specific regulations face compounded risk. A policy that "appears" compliant but functionally grants overprivileged access creates both a security incident and an audit failure.


    ### Insider Threat Amplification


    Silent drift is particularly dangerous for insider threats. An attacker with moderate system access could subtly request LLM-generated policies that contain specific hallucinations or missing conditions—policies that pass code review because they read plausibly but grant unauthorized access.


    ### Accumulation Over Time


    Organizations deploying LLM-generated policies across hundreds or thousands of resources face exponential risk. Each policy is individually small and seemingly inconsequential, but their collective effect can systematically erode access controls across the organization.


    ## Recommendations: Building LLM-Safe Policy Workflows


    ### 1. Treat LLM-Generated Policy Code as Unverified


    Never deploy policies generated by LLMs directly to production. Apply the same rigor you'd apply to any third-party code:

  • Require human review by security engineers
  • Validate policies against your actual system attributes
  • Test policies with known access patterns before deployment

    • ### 2. Establish Attribute Validation Gates


    Before deploying a policy, enforce automated checks:

  • Validate that every attribute referenced in the policy exists in your identity system
  • Cross-reference policy logic against actual data flows
  • Use policy testing frameworks to confirm behavior against synthetic test cases

    • ### 3. Implement Policy Testing and Simulation


  • Create test suites that validate policies grant and deny access as intended
  • Use policy simulators (built into tools like OPA/Rego and Cedar) to trace policy evaluation
  • Test edge cases: time-based policies, role transitions, concurrent access

    • ### 4. Use Fail-Secure Defaults


    Configure your policy engine to deny access when conditions are ambiguous:

  • Use deny by default logic rather than allow by default
  • Require explicit, affirmative grants rather than implicit permissions

    • ### 5. Audit Policy Attribution


    Track which policies were generated by LLMs and apply heightened scrutiny:

  • Tag LLM-generated policies in version control
  • Increase review frequency for policies with AI origins
  • Schedule regular re-validation of LLM-generated policies

    • ### 6. Implement Continuous Policy Monitoring


  • Monitor which policies are being invoked and how often
  • Alert when policy evaluation patterns deviate from expected behavior
  • Track access grant rates and flag anomalies

    • ## Conclusion


    The seduction of LLMs in security engineering is understandable: they're fast, fluent, and confident. But that confidence masks a profound risk in access control. Silent drift—the undetected degradation of authorization policies—operates at the intersection of human trust in AI output and the inherent difficulty of validating policy logic.


    Organizations adopting LLM-assisted policy writing must treat the output not as verified security controls but as draft code requiring rigorous validation. The cost of automation without verification is not measured in hours or compliance audits, but in compromised access control and undetected unauthorized access.


    The path forward is not to abandon LLMs in policy generation, but to build security workflows that treat their output with appropriate skepticism—validating, testing, and continuously monitoring the policies upon which organizational security depends.