{
  "access": "public",
  "type": "reference",
  "format": "markdown",
  "title": "Runtime Policy Enforcement for Autonomous AI Systems",
  "url": "https://app.datagrout.ai/labs/policy",
  "summary": "Autonomous AI agents present fundamental governance challenges. Without runtime policy enforcement, agents can access unauthorized integrations, expose sensitive data, perform destructive operations, and violate compliance requirements. Traditional approaches rely on prompt engineering or post-execution audits, neither of which provide deterministic guarantees about agent behavior.\n\nThis paper introduces a runtime policy enforcement architecture for autonomous systems, comprising two complementary primitives: **Semantic Guards** for pre-execution policy validation and **Dynamic Redaction** for post-execution data masking. Together, these primitives enable declarative policy configuration that enforces integration allowlists, side effect controls, PII protection, and scope verification without requiring agents to reason about compliance.\n\nThe system integrates with Cognitive Trust Certificates (see *Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems*) to provide cryptographic proof that workflows were validated against policies before execution and that sensitive data was redacted according to configuration. Policy enforcement operates over Semio's typed tool contracts (see *Semio: A Semantic Interface Layer for Tool-Oriented AI Systems*), where side effect classifications, PII field annotations, and budget constraints are declared as part of the tool's semantic surface. This transforms agent deployment from \"trust and audit later\" to \"verify then execute with proof.\"",
  "topics": [
    "policy",
    "security",
    "redaction",
    "semantic-guards"
  ],
  "content_markdown": "## Abstract\n\nAutonomous AI agents present fundamental governance challenges. Without runtime policy enforcement, agents can access unauthorized integrations, expose sensitive data, perform destructive operations, and violate compliance requirements. Traditional approaches rely on prompt engineering or post-execution audits, neither of which provide deterministic guarantees about agent behavior.\n\nThis paper introduces a runtime policy enforcement architecture for autonomous systems, comprising two complementary primitives: **Semantic Guards** for pre-execution policy validation and **Dynamic Redaction** for post-execution data masking. Together, these primitives enable declarative policy configuration that enforces integration allowlists, side effect controls, PII protection, and scope verification without requiring agents to reason about compliance.\n\nThe system integrates with Cognitive Trust Certificates (see *Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems*) to provide cryptographic proof that workflows were validated against policies before execution and that sensitive data was redacted according to configuration. Policy enforcement operates over Semio's typed tool contracts (see *Semio: A Semantic Interface Layer for Tool-Oriented AI Systems*), where side effect classifications, PII field annotations, and budget constraints are declared as part of the tool's semantic surface. This transforms agent deployment from \"trust and audit later\" to \"verify then execute with proof.\"\n\n---\n\n## Problem Landscape\n\n### Agents as Security Liability\n\nModern AI agents have broad capabilities but lack granular runtime controls. When an agent is given access to enterprise systems, it typically receives:\n\n- **Unrestricted integration access** - All authenticated APIs are available\n- **Full operation permissions** - Read, write, and delete capabilities\n- **Unfiltered data access** - Complete visibility into API responses\n- **No compliance boundaries** - No enforcement of regulatory requirements\n\nThis creates unacceptable risk:\n- Agents can access integrations they shouldn't (e.g., production database when only dev is authorized)\n- Agents can perform destructive operations (e.g., bulk delete) without approval\n- Agents can expose PII in logs, tool outputs, or LLM context\n- Agents can violate scope restrictions despite OAuth policies\n\n### Prompt Engineering is Insufficient\n\nA common approach is instructing agents to follow policies through system prompts:\n\n```\nYou are an AI assistant. You must:\n- Never access production databases\n- Never delete records without confirmation\n- Always redact PII before logging\n- Only use approved integrations\n```\n\nThis fails because:\n- **Non-deterministic** - LLMs can ignore instructions\n- **Brittle** - Adversarial prompts can override policies\n- **No guarantees** - Cannot prove policy compliance\n- **Poor UX** - Agents spend tokens reasoning about permissions\n\n### Post-Execution Audits Are Too Late\n\nAnother approach is auditing agent actions after execution:\n\n1. Agent performs operations\n2. Logs are reviewed later\n3. Violations are detected\n4. Damage control begins\n\nThis is inadequate because:\n- **Reactive** - Damage occurs before detection\n- **Incomplete** - Not all violations leave audit trails\n- **Resource intensive** - Manual log review doesn't scale\n- **No prevention** - Only detection after the fact\n\n### Compliance as Blocking Concern\n\nEnterprises face regulatory requirements that agents must satisfy:\n\n**GDPR (EU)**:\n- Article 25: Data protection by design\n- Article 32: Security of processing\n- Article 30: Records of processing activities\n\n**CCPA (California)**:\n- Reasonable security procedures\n- Data minimization requirements\n- Consumer rights enforcement\n\n**HIPAA (Healthcare)**:\n- Access controls (Section 164.312)\n- Audit controls (Section 164.312)\n- Data integrity (Section 164.312)\n\n**SOC 2 (Trust Services)**:\n- CC6.1: Logical access controls\n- CC6.6: Management of system operations\n- CC7.2: System monitoring\n\nWithout deterministic policy enforcement, agents cannot operate in regulated environments.\n\n---\n\n## Design Principles\n\n### 1. Declarative Policies, Not Prompt Engineering\n\nPolicies should be configuration, not instructions to the LLM. This enables:\n- **Deterministic enforcement** - Same input, same output\n- **Independent verification** - Third parties can validate policies\n- **No token overhead** - Agents don't reason about permissions\n- **Fail-safe defaults** - Deny unless explicitly allowed\n\n### 2. Defense in Depth\n\nMultiple enforcement points provide layered security:\n- **Pre-execution guards** - Block disallowed operations before they start\n- **Post-execution redaction** - Mask sensitive data in responses\n- **Policy validation in CTCs** - Cryptographic proof of compliance checks\n- **Audit logging** - Record all policy decisions for review\n\n### 3. Zero-Trust for Agents\n\nAgents should have minimal default permissions:\n- **Allowlist integrations** - Only explicitly approved services\n- **Constrain side effects** - Read-only by default, write only when needed\n- **Block destructive ops** - Delete/bulk operations require approval\n- **Verify scopes** - Ensure OAuth permissions match requirements\n\n### 4. Transparent to Agents\n\nPolicy enforcement should not require agent awareness (see *Beyond MCP: The Missing Infrastructure Layer* for the broader argument that intelligence infrastructure should be invisible to agents):\n- **No prompt instructions** - Agents don't need to know about policies\n- **Clean error messages** - Policy violations return standard errors\n- **Automatic compliance** - Happens at infrastructure layer\n- **No reasoning overhead** - Zero tokens spent on permission checks\n\n---\n\n## Semantic Guard Architecture\n\n### Purpose\n\nSemantic Guards are pre-execution policy validators that check if a tool invocation is allowed before any API call occurs. They evaluate policies based on tool metadata and runtime context.\n\n### Guard Primitives\n\n#### Integration Allowlists\n\nControl which services agents can access:\n\n```elixir\npolicy = %{\n  allowed_integrations: [\"salesforce\", \"slack\", \"notion\"]\n}\n\n# Agent tries to call \"stripe\" tool\nSemanticGuard.allow?(server_id, %{integration: \"stripe\"})\n# => {:error, %{code: -32600, message: \"integration_not_allowed\"}}\n```\n\n**Use cases**:\n- Separate dev/staging/production environments\n- Limit agents to approved vendors\n- Enforce integration budget constraints\n- Enable gradual rollout of new integrations\n\n#### Side Effect Controls\n\nRestrict read vs. write operations:\n\n```elixir\npolicy = %{\n  allow_side_effects: [\"read\"]  # Only read operations allowed\n}\n\n# Agent tries to create a record\nSemanticGuard.allow?(server_id, %{side_effect: \"write\"})\n# => {:error, %{code: -32600, message: \"side_effect_blocked\"}}\n```\n\n**Side effect classifications**:\n- `none` - Pure computation, no external state change\n- `read` - Fetch data, no mutations\n- `write` - Create or update records\n- `delete` - Remove data (most restricted)\n\n**Use cases**:\n- Read-only agents for reporting\n- Write protection during testing\n- Approval workflows for mutations\n- Audit requirements for data changes\n\n#### Destructive Operation Blocking\n\nPrevent irreversible actions:\n\n```elixir\npolicy = %{\n  allow_destructive: false\n}\n\n# Agent tries bulk delete\nSemanticGuard.allow?(server_id, %{destructive: true})\n# => {:error, %{code: -32600, message: \"destructive_blocked\"}}\n```\n\n**Destructive markers**:\n- Bulk operations (>10 records)\n- Permanent deletions\n- Schema migrations\n- Configuration changes\n\n**Use cases**:\n- Prevent accidental data loss\n- Require human approval for deletions\n- Enforce backup-before-delete workflows\n- Compliance with retention policies\n\n#### Scope Verification\n\nEnsure OAuth permissions are sufficient:\n\n```elixir\npolicy = %{\n  granted_scopes: [\"read:contacts\", \"read:leads\"]\n}\n\n# Tool requires write permission\nSemanticGuard.allow?(server_id, %{requires_scopes: [\"write:contacts\"]})\n# => {:error, %{code: -32602, message: \"missing_scopes\", \n#      data: %{missing: [\"write:contacts\"]}}}\n```\n\n**Use cases**:\n- Enforce least-privilege OAuth grants\n- Prevent scope creep over time\n- Detect permission mismatches\n- Support multiple auth contexts\n\n#### PII Protection\n\nBlock tools that expose sensitive data when policy forbids:\n\n```elixir\npolicy = %{\n  pii_allowed: false\n}\n\n# Tool is marked as exposing PII\nSemanticGuard.allow?(server_id, %{pii: true})\n# => {:error, %{code: -32600, message: \"pii_blocked\"}}\n```\n\n**PII classifications** (tool metadata):\n- `pii: true` - Tool may return email, phone, SSN, etc.\n- `pii: false` - Tool returns only non-sensitive data\n- `pii_fields: [\"email\", \"ssn\"]` - Specific fields contain PII\n\n**Use cases**:\n- GDPR/CCPA compliance\n- Minimize data exposure to LLMs\n- Separate dev/prod data policies\n- Support data residency requirements\n\n#### Dynamic Risk Assessment\n\nDetect PII in arguments even if tool isn't flagged:\n\n```elixir\npolicy = %{\n  pii_allowed: false\n}\n\n# Agent passes email in arguments\nSemanticGuard.allow?(server_id, %{pii: false}, %{\n  email: \"user@example.com\"\n})\n# => {:error, %{code: -32600, message: \"pii_detected_in_args\"}}\n```\n\n**Detection heuristics**:\n- Email patterns (`@` symbol, domain format)\n- SSN patterns (XXX-XX-XXXX)\n- Credit card patterns (16 digits)\n- Phone patterns (parentheses, hyphens)\n\n**Use cases**:\n- Catch accidental PII exposure\n- Prevent agents from leaking data\n- Enforce input sanitization\n- Support zero-trust data handling\n\n### Policy Composition\n\nPolicies can be layered with inheritance:\n\n```elixir\n# Server-level policy (base)\nserver_policy = %{\n  allow_side_effects: [\"read\", \"write\"],\n  allow_destructive: false,\n  pii_allowed: false\n}\n\n# Integration-specific override\nsalesforce_policy = Map.merge(server_policy, %{\n  pii_allowed: true,  # Salesforce needs PII access\n  required_scopes: [\"read:leads\", \"write:leads\"]\n})\n```\n\n**Inheritance rules**:\n- Server policy is the base default\n- Integration policies merge on top, per integration\n- Tool policies can further constrain\n- Most restrictive policy wins; child policies can only tighten, never loosen\n\n### Conflict Resolution\n\nPolicy conflicts are resolved by monotonic restriction. An integration- or mux-level policy cannot grant permissions that the server-level policy denies. Child overrides may only tighten the parent posture: side effects clamp to a subset, destructive access cannot be widened, PII access cannot be widened, Warden settings may only become stricter, and field redactions remain additive. There is no implicit PII carve-out at the child layer. If a future workflow needs an exception, it should be modeled as an explicit approval capability rather than a hidden policy override.\n\nWhen a tool requires access that the resolved policy forbids (e.g., a workflow requires PII access to function but policy blocks it), the tool invocation is rejected with a structured error. There is no automatic escalation or override. The user must explicitly adjust the policy. This fail-closed design ensures that policy violations are never silently resolved.\n\n### Enforcement Invariant\n\nEvery tool invocation, regardless of entry point, passes through the same enforcement chain: **Lookup -> Guard -> Execute -> Redact**. This pattern is an architectural invariant maintained across all execution paths. The MCP gateway, interactive sandbox, and agentic loop all apply identical policy enforcement. No execution path bypasses the guard or the redactor.\n\n---\n\n## Dynamic Redaction Architecture\n\n### Purpose\n\nRedactors mask sensitive data in tool responses after execution but before returning to agents. This provides defense-in-depth: even if a guard is bypassed, sensitive data is still protected.\n\n### Redaction Strategies\n\n#### Field-Aware Masking\n\nTarget specific fields with appropriate masking:\n\n```elixir\npolicy = %{\n  field_redactions: %{\n    \"email\" => \"mask_email\",\n    \"phone\" => \"mask_phone\",\n    \"ssn\" => \"mask_all\"\n  }\n}\n\n# Original response\n%{\n  name: \"John Doe\",\n  email: \"john.doe@example.com\",\n  phone: \"(555) 123-4567\"\n}\n\n# Redacted response\n%{\n  name: \"John Doe\",\n  email: \"j*******@e******.com\",\n  phone: \"(**) ***-****\"\n}\n```\n\n**Masking strategies**:\n- `mask_email` - Preserve structure, mask local/domain parts\n- `mask_phone` - Replace digits with asterisks\n- `mask_all` - Replace entire value with fixed-length mask\n- `apron` - Keep N chars at start/end, mask middle\n\n#### Apron Masking\n\nPreserve prefix/suffix for readability:\n\n```elixir\npolicy = %{\n  field_redactions: %{\n    \"api_key\" => %{\n      \"strategy\" => \"apron\",\n      \"apron\" => 3  # Keep 3 chars on each end\n    }\n  }\n}\n\n# Original: \"sk_live_4eC39HqLyjWDarjtT1zdp7dc\"\n# Redacted: \"sk_******************7dc\"\n```\n\n**Configuration**:\n- `apron: N` - Number of characters to preserve\n- `mask_char: \"*\"` - Character for masking (default: `*`)\n- `fixed_length: M` - Always produce M-length mask\n\n**Use cases**:\n- API keys (show prefix for debugging)\n- Tokens (preserve format hints)\n- IDs (maintain length for UI spacing)\n- Account numbers (last 4 digits visible)\n\n#### Structure-Preserving Scrambling\n\nGenerate realistic fake data that maintains format:\n\n```elixir\npolicy = %{\n  field_redactions: %{\n    \"email\" => \"scramble\",\n    \"phone\" => \"scramble\",\n    \"ssn\" => \"scramble\"\n  }\n}\n\n# Original\n%{\n  email: \"john.smith@acme.com\",\n  phone: \"(555) 123-4567\",\n  ssn: \"123-45-6789\"\n}\n\n# Scrambled (realistic fakes)\n%{\n  email: \"jane.jones@example.com\",\n  phone: \"(722) 456-8901\",\n  ssn: \"234-56-7890\"\n}\n```\n\nScrambled values are deterministic: the same input produces the same fake output across invocations, ensuring consistency in logs and audit trails without exposing real data. Determinism is achieved through keyed hashing with a deployment-specific salt, so scrambled values cannot be reversed or predicted across deployments.\n\n**Generation rules**:\n- **Emails**: Random first/last name + test domains\n- **Phones**: Random area codes (200-999 range)\n- **SSNs**: Random valid format (not real numbers)\n- **Dates**: Random dates in past 50 years\n- **Names**: Pool of common first/last names\n- **Addresses**: Random street numbers + common streets\n\n**Use cases**:\n- Development/testing with realistic data\n- Demo environments with fake but structured data\n- UI testing without exposing real PII\n- Training datasets with privacy preservation\n\n#### Auto-Masking on Policy Mismatch\n\nAggressive redaction when tool PII flag conflicts with policy:\n\n```elixir\npolicy = %{\n  pii_allowed: false\n}\n\ntool_meta = %{\n  pii: true  # Tool may return PII\n}\n\n# Response contains obvious PII\nresponse = %{\n  contact: \"john@example.com\"\n}\n\n# Auto-masked despite passing guard\n%{\n  contact: \"j***@e******.com\"\n}\n```\n\n**Triggers**:\n- Tool marked `pii: true` but policy says `pii_allowed: false`\n- Pattern matching finds email/phone despite tool not flagged\n- Dynamic risk detection in arguments\n\n**Use cases**:\n- Belt-and-suspenders PII protection\n- Catch tool metadata errors\n- Enforce data minimization\n- Support defense-in-depth\n\n### Configurable Per-Integration\n\nDifferent integrations need different policies:\n\n```elixir\nsalesforce_policy = %{\n  field_redactions: %{\n    \"Email\" => \"apron_2\",\n    \"Phone\" => \"mask_phone\"\n  }\n}\n\nstripe_policy = %{\n  field_redactions: %{\n    \"card\" => %{\n      \"strategy\" => \"apron\",\n      \"apron\" => 4  # Show last 4 digits\n    },\n    \"ssn_last_4\" => \"mask_all\"\n  }\n}\n```\n\n---\n\n## Integration with Cognitive Trust Certificates\n\n### Identity-Anchored Enforcement\n\nPolicy enforcement presupposes authenticated identity: the system must know *who* is subject to a policy before it can evaluate *what* they are allowed to do. In substrate and conduit environments, identity is established through the platform's Certificate Authority, which issues short-lived X.509 certificates for mutual TLS authentication (see *Arbiter Substrate: OS-Level Governance for Autonomous AI Agents* for the certificate lifecycle). Every policy evaluation occurs within an mTLS session where the caller's identity has already been cryptographically verified against the CA chain. This means policy decisions are bound to a verified principal, not to a bearer token that could be replayed or shared.\n\nThe same CA root that authenticates the caller also anchors the CTC signatures that prove policy compliance after validation. Identity verification and compliance proof share a common trust root, creating an unbroken chain from \"who is asking\" through \"what are they allowed to do\" to \"proof that what they did was validated.\"\n\n### Policy Validation During CTC Generation\n\nWhen a CTC is generated for a workflow plan (see *Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems*), every step is checked against the active policy. If any step violates policy (blocked integration, disallowed side effect, PII exposure without clearance), CTC generation fails and the plan is rejected before execution.\n\nThe CTC records which policies were enforced, including a snapshot of the policy configuration at validation time. This snapshot is included in the CTC evidence, ensuring that auditors can verify what rules were in effect when the plan was approved.\n\n### Execution Requires Valid CTC\n\nWorkflows cannot execute without a valid CTC that includes policy validation evidence. The execution layer verifies the CTC signature and confirms the policy snapshot before allowing any tool invocation.\n\n### Audit Trail Completeness\n\nThe combination of CTCs and policy enforcement provides a complete audit trail:\n\n1. **Pre-execution**: CTC proves policies were validated\n2. **During execution**: Guards enforce policies in real-time\n3. **Post-execution**: Redactor masks sensitive data\n4. **Audit**: CTC + execution logs show complete lineage\n\nFor compliance audits: show the CTC proving validation, show the policy configuration at execution time, show redaction was applied, and prove cryptographically that the workflow matched the validated plan.\n\n---\n\n## Enterprise Implications\n\n### Compliance Enablement\n\n**GDPR Article 25 (Data Protection by Design)**:\n- Policies enforce data minimization by default\n- PII protection is architectural, not procedural\n- Redaction ensures \"privacy by design and by default\"\n\n**GDPR Article 30 (Records of Processing)**:\n- CTCs provide immutable record of what tools accessed what data\n- Policy snapshots show what controls were in place\n- Audit logs demonstrate continuous compliance\n\n**SOC 2 CC6.1 (Logical Access Controls)**:\n- Integration allowlists enforce least-privilege access\n- Scope verification ensures proper authorization\n- Policy inheritance supports role-based access\n\n**HIPAA Section 164.312(a)(1) (Access Control)**:\n- Semantic Guards implement required access controls\n- Policies define who/what can access PHI\n- Audit trails support compliance demonstrations\n\n### Risk Mitigation\n\n**Prevent Data Breaches**:\n- PII detection stops accidental exposure\n- Redaction provides defense-in-depth\n- Integration allowlists limit blast radius\n\n**Prevent Destructive Operations**:\n- Destructive operation blocking prevents data loss\n- Approval workflows for high-risk actions\n- Side effect controls enforce read-only where appropriate\n\n**Enable Incident Response**:\n- Complete audit trail for forensics\n- Policy snapshots show what was allowed\n- CTC evidence supports root cause analysis\n\n### Operational Benefits\n\n**Developer Experience**:\n- Declarative policies are readable\n- No prompt engineering for permissions\n- Policies version-controlled with code\n\n**Scalability**:\n- Policies enforce automatically at runtime\n- No manual review of agent actions\n- Deterministic enforcement across all agents\n\n**Gradual Rollout**:\n- Start with restrictive policies\n- Expand permissions incrementally\n- Test in dev before prod\n\n**Multi-Tenancy**:\n- Per-server policies for isolation\n- Per-integration overrides for flexibility\n- Inheritance reduces duplication\n\n---\n\n## Policy Configuration Examples\n\n### Development Environment\n\nRestrictive policies for testing:\n\n```yaml\nallow_side_effects:\n  - read\nallow_destructive: false\npii_allowed: false\nallowed_integrations:\n  - salesforce_sandbox\n  - slack_dev\nfield_redactions:\n  email: scramble\n  phone: scramble\n  ssn: mask_all\n```\n\n### Production Environment\n\nMore permissive but with redaction:\n\n```yaml\nallow_side_effects:\n  - read\n  - write\nallow_destructive: false  # Still no destructive ops\npii_allowed: true  # Allow PII access\nallowed_integrations:\n  - salesforce_prod\n  - slack_prod\n  - stripe_prod\nfield_redactions:\n  email: apron_2\n  phone: mask_phone\n  card: apron_4\n  ssn: mask_all\n```\n\n### Read-Only Analyst Agent\n\nFor reporting and analytics:\n\n```yaml\nallow_side_effects:\n  - read\nallow_destructive: false\npii_allowed: false\nallowed_integrations:\n  - warehouse\n  - analytics\n  - reporting\nfield_redactions:\n  email: mask_email\n  user_id: fixed_length_10\n```\n\n### Administrative Agent\n\nHigher privileges, human approval required:\n\n```yaml\nallow_side_effects:\n  - read\n  - write\n  - delete  # Only for admin agent\nallow_destructive: true  # With approval workflow\npii_allowed: true\nallowed_integrations: any\nfield_redactions:\n  ssn: mask_all  # Always mask SSN\n  card: apron_4  # Show last 4\n```\n\n---\n\n## Performance Considerations\n\n### Guard Evaluation Overhead\n\nPolicy checks add minimal latency:\n- **Integration check**: O(1) hash lookup\n- **Side effect check**: O(1) set membership\n- **Scope verification**: O(n) where n = number of scopes\n- **PII detection**: O(m) where m = argument depth\n\nTypical overhead: **<5ms per tool call**\n\n### Redaction Performance\n\nMasking strategies have different costs:\n- **Simple masking**: O(n) where n = string length\n- **Apron masking**: O(n) string operations\n- **Scrambling**: O(n) + random generation\n- **Deep walk**: O(d * k) where d = depth, k = keys\n\nTypical overhead: **<10ms per response**\n\n### Optimization Strategies\n\n**Policy Caching**:\n- Pre-compile policies at server startup\n- Cache policy lookups by server_id\n- Invalidate cache on policy updates\n\n**Lazy Evaluation**:\n- Check integration allowlist first (fail fast)\n- Skip PII detection if policy allows PII\n- Short-circuit on first violation\n\n**Batching**:\n- Validate multiple steps in single pass\n- Apply redaction to batched responses\n- Amortize policy fetch overhead\n\n---\n\n## Future Directions\n\n### Policy Intelligence\n\nBehavioral analysis of agent operations could inform policy recommendations: identifying unused integration permissions, detecting overly permissive scopes, and suggesting least-privilege configurations based on observed access patterns.\n\n### Advanced Redaction\n\nPotential extensions include tokenization (reversible masking for authorized users), format-preserving encryption, and contextual redaction that adapts masking strategy based on the recipient's authorization level.\n\n---\n\n## Appendix: Policy Decision Flow\n\n### Pre-Execution (Semantic Guard)\n\n```\nAgent requests tool execution\n         |\nExtract policy for server/integration\n         |\nCheck integration allowlist\n  - Not allowed -> Deny\n  - Allowed -> Continue\n         |\nCheck side effect permissions\n  - Not allowed -> Deny\n  - Allowed -> Continue\n         |\nCheck destructive flag\n  - Blocked -> Deny\n  - Allowed -> Continue\n         |\nCheck OAuth scopes\n  - Missing scopes -> Deny\n  - Scopes sufficient -> Continue\n         |\nCheck PII flag\n  - PII blocked -> Deny\n  - Allowed -> Continue\n         |\nCheck for PII in arguments\n  - PII detected -> Deny\n  - Clean -> Allow\n         |\nExecute tool\n```\n\n### Post-Execution (Redactor)\n\n```\nTool returns response\n         |\nExtract redaction policy\n         |\nWalk response structure\n  - For each field:\n    - Check field_redactions config\n    - Apply masking strategy\n    - Replace value\n  - Continue\n         |\nCheck for auto-masking conditions\n  - Tool PII=true, Policy PII=false\n    - Apply aggressive masking\n  - Continue\n         |\nReturn redacted response\n```\n\n---\n\n*This document describes the conceptual architecture of runtime policy enforcement for autonomous systems. Specific detection heuristics, masking algorithms, and performance optimizations are withheld to protect operational security while enabling understanding of the governance model.*\n",
  "last_updated": "2026-01-25T00:00:00Z"
}