Mike Anderson's latest deep-dive on DEV.to picks up where his harness design theory left off: turning abstract principles into a working implementation pattern for regulated industries. The example? A fictional ZYX Bank building what they call the "ZYX Secure Engineering Assistant"—an internal tool that reviews infrastructure changes before deployment without ever touching production directly.

Why Banks Can't Just Wire Up Chatbots to Jira and AWS

The core argument is straightforward: a bank doesn't need an AI agent that can randomly call Jira, GitHub, Slack, AWS, and Confluence with no guardrails. They need controlled delegation. The model can reason about risk, but the harness must decide who makes requests, what data gets retrieved, which tools are callable, which actions require human approval, what's logged versus blocked, and how security teams can kill the workflow instantly. This is fundamentally different from building a general-purpose assistant. It's about creating value through analysis and recommendations while maintaining deterministic control over what the system can actually touch. The agent reviews, comments, and notifies—it cannot deploy, merge pull requests, modify IAM policies directly, or change security groups without approval.

Five-Layer Architecture That Puts Policy in Charge

The implementation uses a strict hierarchy: Engineer → FastAPI Agent Portal → Policy Gateway → Secure Harness → Controlled Tools → Validation + Audit Logging. Every request flows through authentication, group membership checks, device posture verification, request classification, tool authorization, controlled context retrieval, analysis execution, output validation, approved output posting, and audit logging. The critical design constraint? "The model does not decide authorization. The policy gateway does." This separation between reasoning (what the AI does) and enforcement (what the system allows) is where most enterprise AI projects go wrong—they embed controls in prompts instead of building deterministic checkpoints into the execution path.

Policy as Code: YAML Definitions Enforced by Python

The tool_policies.yaml file defines every connector with explicit risk levels, allowed group memberships, account restrictions, write permissions, and approval requirements. The PolicyGateway class in app/policy.py loads this configuration and enforces it through a series of deterministic checks including kill switch logic for disabling all write tools or specific connectors globally. Device compliance verification happens at authorization time—if the user's endpoint isn't marked compliant, tool access gets denied regardless of group membership. For high-risk operations like modifying security groups across staging accounts, approval requirements cascade: change tickets and rollback plans become mandatory before the policy gateway permits execution.

Validation Layer Catches Secrets and Prompt Injection

The validation.py module implements regex-based detection for secret patterns (AWS access keys, API keys, private key headers) and prompt injection indicators ("ignore previous instructions", "export all", "send to external"). When output validation fails—meaning the agent's response might contain credentials or has been compromised by injection—the system raises an exception rather than forwarding dangerous content downstream. Anderson notes this is deliberately minimal: a starter validation layer that proves the pattern works locally before wiring into production enterprise systems with proper DLP engines, structured schema validation, evidence-backed claims, and data classification labels.

Audit Logging Every Decision to JSONL

The audit.py module generates trace IDs in format "ai-YYYYMMDD-hash" and writes every policy decision, tool usage event, approval status, and agent completion result to audit_events.jsonl. Each entry captures user identity, group memberships, device posture, ticket metadata, repository context, pull request details, and full tool decision chains. This creates the paper trail that compliance teams in banking, healthcare, and insurance require—complete traceability from user request through model reasoning to output generation with no gaps for auditors to question.

Key Takeaways

  • Policy enforcement must be deterministic code, not advisory prompt instructions—the model recommends, the gateway decides
  • Group-based access control combined with device posture checks creates defense in depth at authorization time
  • Kill switches let security teams disable write tools or entire connector categories without touching application code
  • Output validation catches both accidental credential leakage and adversarial prompt injection attempts
  • JSONL audit logs forward to SIEM pipelines provide complete traceability for compliance requirements

The Bottom Line

This implementation pattern is exactly what regulated industries need—proof that AI can add value in security review workflows without creating new attack surfaces or bypassing existing controls. The question isn't whether banks should use AI agents; it's whether they'll build proper harnesses or just slap REST APIs on unconstrained LLM calls and hope for the best.