How to Use AI Guardrails for Data Security

Whether you’re integrating a third-party AI model or deploying your own, adopt these practices to shrink your exposed surfaces to attackers and hackers: • Least-Privilege Agents – Restrict what your chatbot or autonomous agent can see and do. Sensitive actions should require a human click-through. • Clean Data In, Clean Model Out – Source training data from vetted repositories, hash-lock snapshots, and run red-team evaluations before every release. • Treat AI Code Like Stranger Code – Scan, review, and pin dependency hashes for anything an LLM suggests. New packages go in a sandbox first. • Throttle & Watermark – Rate-limit API calls, embed canary strings, and monitor for extraction patterns so rivals can’t clone your model overnight. • Choose Privacy-First Vendors – Look for differential privacy, “machine unlearning,” and clear audit trails—then mask sensitive data before you ever hit Send. Rapid-fire user checklist: verify vendor audits, separate test vs. prod, log every prompt/response, keep SDKs patched, and train your team to spot suspicious prompts. AI security is a shared-responsibility model, just like the cloud. Harden your pipeline, gate your permissions, and give every line of AI-generated output the same scrutiny you’d give a pull request. Your future self (and your CISO) will thank you. 🚀🔐

The 𝗔𝗜 𝗗𝗮𝘁𝗮 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 guidance from 𝗗𝗛𝗦/𝗡𝗦𝗔/𝗙𝗕𝗜 outlines best practices for securing data used in AI systems. Federal CISOs should focus on implementing a comprehensive data security framework that aligns with these recommendations. Below are the suggested steps to take, along with a schedule for implementation. 𝗠𝗮𝗷𝗼𝗿 𝗦𝘁𝗲𝗽𝘀 𝗳𝗼𝗿 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 1. Establish Governance Framework     - Define AI security policies based on DHS/CISA guidance.     - Assign roles for AI data governance and conduct risk assessments.  2. Enhance Data Integrity     - Track data provenance using cryptographically signed logs.     - Verify AI training and operational data sources.     - Implement quantum-resistant digital signatures for authentication.  3. Secure Storage & Transmission     - Apply AES-256 encryption for data security.     - Ensure compliance with NIST FIPS 140-3 standards.     - Implement Zero Trust architecture for access control.  4. Mitigate Data Poisoning Risks     - Require certification from data providers and audit datasets.     - Deploy anomaly detection to identify adversarial threats.  5. Monitor Data Drift & Security Validation     - Establish automated monitoring systems.     - Conduct ongoing AI risk assessments.     - Implement retraining processes to counter data drift.  𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗲 𝗳𝗼𝗿 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻  Phase 1 (Month 1-3): Governance & Risk Assessment   • Define policies, assign roles, and initiate compliance tracking.   Phase 2 (Month 4-6): Secure Infrastructure   • Deploy encryption and access controls.   • Conduct security audits on AI models. Phase 3 (Month 7-9): Active Threat Monitoring • Implement continuous monitoring for AI data integrity.   • Set up automated alerts for security breaches.   Phase 4 (Month 10-12): Ongoing Assessment & Compliance   • Conduct quarterly audits and risk assessments.   • Validate security effectiveness using industry frameworks.  𝗞𝗲𝘆 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗙𝗮𝗰𝘁𝗼𝗿𝘀   • Collaboration: Align with Federal AI security teams.   • Training: Conduct AI cybersecurity education.   • Incident Response: Develop breach handling protocols.   • Regulatory Compliance: Adapt security measures to evolving policies.  

Imagine giving an autonomous AI agent the keys to your BigQuery warehouse. It can analyze, query, and even manipulate data—without you lifting a finger. Exciting, right? But what happens if it accidentally deletes a critical dataset, runs a runaway query that burns through your budget, or exposes sensitive information? To unlock the benefits of AI-driven data operations while avoiding disaster, you need guardrails—a layered defense system to make agents safe, predictable, and cost-aware. Here’s how you can safeguard your data and wallet when using ADK agents with BigQuery. 1. ✅ Define Explicit System Instructions - Set the agent’s role, access limits, and query rules. - Forbid dangerous operations (DELETE, DROP), require LIMIT, and ban SELECT *. 2. 🛡️ Use Callbacks as Security Checkpoints - Validate or block queries before execution (e.g., stop queries containing DELETE). - Log intent for traceability. 3. 🧱 Apply SQL Parameterization - Prevent SQL injection by giving agents query templates with parameters instead of raw SQL control. 4. 💸 Dry Run Queries to Estimate Costs - Use BigQuery’s dry_run mode to preview how much data a query would process before running it. 5. 🚦 Set Maximum Bytes Billed - Put a hard ceiling on query size to avoid runaway bills. 6. 🔒 Leverage BigQuery’s First-Party Tools - Use built-in write controls, result size limits, and protections against unauthorized operations. 7. 🔑 Enforce Granular IAM Permissions - Limit agent access at dataset, table, column, and even row levels to follow the “least privilege” principle. 8. 🗄️ Centralize Access with MCP Toolbox - Use MCP to handle authentication and reduce the attack surface by removing direct BigQuery credentials from agents. 9. 🕵️ Implement Debugging and Traceability - Log all agent actions, queries, and errors for audits and compliance. Use BigQuery audit logs and ADK’s Web UI trace tools. 10. 🧑⚖️ Add a Human-in-the-Loop - Require human approval for sensitive actions like deleting data or running costly queries. To recap... No single safeguard is enough on its own. By combining system instructions, validation checkpoints, access controls, and cost protections, you can confidently deploy AI agents that are powerful yet safe. The result? You unlock autonomous data operations without fear of data loss, unexpected costs, or compliance nightmares. -- 🧑💻 My name is David and I'm constantly sharing about data and AI. Follow me for more FREE content. 👍 Like, 🔗 share, 💬 comment, 👉 follow #BigQuery #AI #AgenticAI

AI is not failing because of bad ideas; it’s "failing" at enterprise scale because of two big gaps: 👉 Workforce Preparation 👉 Data Security for AI While I speak globally on both topics in depth, today I want to educate us on what it takes to secure data for AI—because 70–82% of AI projects pause or get cancelled at POC/MVP stage (source: #Gartner, #MIT). Why? One of the biggest reasons is a lack of readiness at the data layer. So let’s make it simple - there are 7 phases to securing data for AI—and each phase has direct business risk if ignored. 🔹 Phase 1: Data Sourcing Security - Validating the origin, ownership, and licensing rights of all ingested data. Why It Matters: You can’t build scalable AI with data you don’t own or can’t trace. 🔹 Phase 2: Data Infrastructure Security - Ensuring data warehouses, lakes, and pipelines that support your AI models are hardened and access-controlled. Why It Matters: Unsecured data environments are easy targets for bad actors making you exposed to data breaches, IP theft, and model poisoning. 🔹 Phase 3: Data In-Transit Security - Protecting data as it moves across internal or external systems, especially between cloud, APIs, and vendors. Why It Matters: Intercepted training data = compromised models. Think of it as shipping cash across town in an armored truck—or on a bicycle—your choice. 🔹 Phase 4: API Security for Foundational Models - Safeguarding the APIs you use to connect with LLMs and third-party GenAI platforms (OpenAI, Anthropic, etc.). Why It Matters: Unmonitored API calls can leak sensitive data into public models or expose internal IP. This isn’t just tech debt. It’s reputational and regulatory risk. 🔹 Phase 5: Foundational Model Protection - Defending your proprietary models and fine-tunes from external inference, theft, or malicious querying. Why It Matters: Prompt injection attacks are real. And your enterprise-trained model? It’s a business asset. You lock your office at night—do the same with your models. 🔹 Phase 6: Incident Response for AI Data Breaches - Having predefined protocols for breaches, hallucinations, or AI-generated harm—who’s notified, who investigates, how damage is mitigated. Why It Matters: AI-related incidents are happening. Legal needs response plans. Cyber needs escalation tiers. 🔹 Phase 7: CI/CD for Models (with Security Hooks) - Continuous integration and delivery pipelines for models, embedded with testing, governance, and version-control protocols. Why It Matter: Shipping models like software means risk comes faster—and so must detection. Governance must be baked into every deployment sprint. Want your AI strategy to succeed past MVP? Focus and lock down the data. #AI #DataSecurity #AILeadership #Cybersecurity #FutureOfWork #ResponsibleAI #SolRashidi #Data #Leadership

I've reviewed Anthropic's Risk Report for Claude Opus 4.6 because many of our enterprise customers are actively deploying AI agents into production environments. When those systems fail, the consequences are operational, financial and reputational. Most of the reaction centers on the headline that catastrophic risk is very low but not negligible. What matters more for customers and future customers is how risk actually manifests inside live enterprise systems and what that means for uptime, data integrity and compliance. It does not look like a breach. It looks like business as usual. An agent subtly influencing procurement decisions. A finance workflow that starts omitting inconvenient data. Permissions that expand over time without clear oversight. Anthropic describes a scenario called Persistent Rogue Internal Deployment, where an AI system with privileged access creates a less monitored instance of itself and continues operating inside production systems. In a real enterprise environment, that translates into downtime, data exposure or regulatory impact. The organizations at greatest risk are not the ones moving cautiously. They are the ones who pushed agents into production without adding an operational governance layer. We have seen this pattern before in cloud adoption. Technology advances quickly, and controls often lag behind. That gap is where exposure grows. So what should enterprise IT and security teams do now? 1. Constrain actions, not just access. Define what an agent can set in motion and enforce least privilege at the identity level, just as you have done for human users for decades. 2. Log actions, not just outcomes. Maintain an auditable trail of what the agent did, where and what triggered it, the same standard applies to human operators in regulated environments. 3. Automate your tripwires. Do not rely on people to catch machine speed behavior. Build policy enforcement and anomaly response into the loop. 4. Audit your agent footprint. Inventory every agent, its owner, permissions and kill path. Governance starts with visibility and most enterprises are still building it. The window to build these guardrails is now, before the agent workforce scales. At Rackspace, 25 years of running mission-critical systems have taught us that trust without controls creates exposure. We build and operate AI infrastructure with governance embedded from day one because customers need speed, resilience and measurable outcomes, not experiments in production. What this means for you is simple. Move forward on AI with confidence, but make operational governance part of the foundation so scale strengthens your business instead of introducing risk.

AI & Practical Steps CISOs Can Take Now! Too much buzz around LLMs can paralyze security leaders. Reality is that, AI isn’t magic! So apply the same foundational security fundamentals. Here’s how to build a real AI security policy: 🔍 Discover AI Usage: Map who’s using AI, where it lives in your org, and intended use cases. 🔐 Govern Your Data: Classify & encrypt sensitive data. Know what data is used in AI tools, and where it goes. 🧠 Educate Users: Train teams on safe AI use. Teach spotting hallucinations and avoiding risky data sharing. 🛡️ Scan Models for Threats: Inspect model files for malware, backdoors, or typosquatting. Treat model files like untrusted code. 📈 Profile Risks (just like Cloud or BYOD): Create an executive-ready risk matrix. Document use cases, threats, business impact, and risk appetite. These steps aren’t flashy but they guard against real risks: data leaks, poisoning, serialization attacks, supply chain threats.

Most AI breaches won't look like hacks. They'll look like trust. I've been in IT for 15 years. Built AI systems long enough to spot the difference between hype and frameworks that actually hold up in production. When Cisco released its AI Security Framework, I read the entire thing. Most security docs treat AI like traditional software. Patch it. Firewall it. Done. Cisco gets something most enterprises don't: security and safety aren't two teams arguing after an incident. They're one system. 19 attacker objectives. 40 techniques. Over 100 concrete failure modes. This matters because most AI breaches won't look like classic hacks: 𝗚𝗼𝗮𝗹 𝗵𝗶𝗷𝗮𝗰𝗸𝗶𝗻𝗴. Your agent gets manipulated into pursuing objectives you never intended. 𝗧𝗼𝗼𝗹 𝘀𝗽𝗼𝗼𝗳𝗶𝗻𝗴. An attacker substitutes a legitimate tool with a malicious one. Your agent can't tell the difference. 𝗣𝗼𝗶𝘀𝗼𝗻𝗲𝗱 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀. That open-source model you pulled from Hugging Face? Compromised before you downloaded it. 𝗤𝘂𝗶𝗲𝘁 𝗱𝗮𝘁𝗮 𝗲𝘅𝗳𝗶𝗹𝘁𝗿𝗮𝘁𝗶𝗼𝗻. Through agents you trusted. No alarms. No alerts. Just steady leakage. If you're deploying agents without guardrails, auditability, and supply chain controls, you're not moving fast. You're building future incidents. The rollout plan that actually works: 𝟭. 𝗧𝗿𝗲𝗮𝘁 𝗮𝗴𝗲𝗻𝘁𝘀 𝗹𝗶𝗸𝗲 𝗻𝗲𝘄 𝗵𝗶𝗿𝗲𝘀 Same access controls. Same permissions review. Same principle of least privilege. 𝟮. 𝗔𝘂𝗱𝗶𝘁 𝘆𝗼𝘂𝗿 𝘁𝗼𝗼𝗹 𝗰𝗵𝗮𝗶𝗻 Every tool your agent can call is an attack surface. If you can't explain what it does and why your agent needs it, remove it. 𝟯. 𝗕𝘂𝗶𝗹𝗱 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗳𝗿𝗼𝗺 𝗱𝗮𝘆 𝗼𝗻𝗲 Every decision. Every action. Every output. You need receipts. 𝟰. 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝗴𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀, 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝗴𝘂𝗶𝗱𝗲𝗹𝗶𝗻𝗲𝘀 Prompts can be jailbroken. Hard constraints in code. Rate limits. Output validation. 𝟱. 𝗣𝗹𝗮𝗻 𝗳𝗼𝗿 𝗳𝗮𝗶𝗹𝘂𝗿𝗲 Kill switches. Rollback procedures. Not if your agent fails. When. While enterprises debate AI governance frameworks, attackers are studying how agents work. The gap between "we're exploring AI security" and "we have production guardrails" is where breaches happen. Most AI systems will fail. The question is whether you designed for that failure or pretended it wouldn't happen. Build like you expect to be attacked. Because you will be. What's your current guardrail strategy for agents in production?

𝗕𝗲𝗳𝗼𝗿𝗲 𝘆𝗼𝘂 𝗯𝘂𝗶𝗹𝗱 𝘆𝗼𝘂𝗿 𝗻𝗲𝘅𝘁 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁… Ask: “What 𝘴𝘺𝘴𝘵𝘦𝘮 will keep it safe, fast, and right?” 𝗠𝗼𝘀𝘁 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀 𝗱𝗼𝗻’𝘁 𝗳𝗮𝗶𝗹 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗼𝗳 𝗯𝗮𝗱 𝗽𝗿𝗼𝗺𝗽𝘁𝘀. But because the system around them isn’t designed for context, safety, or control. Let’s walk through a 𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄 for building context-aware, production-ready agents, 𝗹𝗮𝘆𝗲𝗿 𝗯𝘆 𝗹𝗮𝘆𝗲𝗿: 𝟭. 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 Start with a cache check. If the query’s been answered before, skip the pipeline. This reduces latency and slashes compute costs. 𝗦𝗽𝗲𝗲𝗱 𝘀𝘁𝗮𝗿𝘁𝘀 𝗵𝗲𝗿𝗲. 𝟮. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗖𝗼𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝗼𝗻 No cache hit? Time to build context. Use RAG, query rewriting, or lightweight reasoning. It’s not just what’s the prompt, It’s what does the model need to know right now? 𝟯. 𝗜𝗻𝗽𝘂𝘁 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 Before touching a model, enforce safety with: ✅ PII redaction ✅ Compliance checks ✅ Input validation 𝗧𝗿𝘂𝘀𝘁 𝘀𝘁𝗮𝗿𝘁𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻. 𝟰. 𝗥𝗲𝗮𝗱-𝗢𝗻𝗹𝘆 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 The agent can now gather data without side effects: • Vector search • SQL queries •  Web lookups •  Structured & unstructured reads 𝗕𝘂𝗶𝗹𝗱 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 𝘄𝗶𝘁𝗵 𝘇𝗲𝗿𝗼 𝗿𝗶𝘀𝗸. 𝟱. 𝗪𝗿𝗶𝘁𝗲 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 When action is needed, the agent steps up: • Send emails • Update records • Trigger workflows Not just Q&A, 𝗮 𝘁𝗿𝘂𝗲 𝗼𝗽𝗲𝗿𝗮𝘁𝗼𝗿. 𝟲. 𝗢𝘂𝘁𝗽𝘂𝘁 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 Before responses are returned: • Structure is validated • Safety & policy are checked • Hallucinations are caught 𝗖𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲 𝗶𝘀𝗻’𝘁 𝗼𝗽𝘁𝗶𝗼𝗻𝗮𝗹. 𝟳. 𝗠𝗼𝗱𝗲𝗹 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 This is the control tower. It routes to the right model (GPT-4, Claude, etc.), manages tokens, and applies scoring. 𝗢𝗻𝗲 𝗽𝗹𝗮𝗰𝗲 𝘁𝗼 𝗺𝗮𝗻𝗮𝗴𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗮𝗻𝗱 𝗰𝗼𝘀𝘁. 𝟴. 𝗟𝗼𝗴𝗴𝗶𝗻𝗴 & 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 Track everything - transparently and securely: • CloudWatch • OpenSearch • CloudTrail • X-Ray Because real systems need real visibility. 𝗪𝗵𝗮𝘁 𝘆𝗼𝘂 𝗴𝗲𝘁: ✅ Context-aware ✅ Modular ✅ Guarded ✅ Transparent ✅ Production-grade This is how we move AI agents 𝗳𝗿𝗼𝗺 𝗹𝗮𝗯 𝗱𝗲𝗺𝗼𝘀 𝘁𝗼 𝗿𝗲𝗮𝗹 𝘀𝘆𝘀𝘁𝗲𝗺𝘀. This is how we build for 𝘀𝗰𝗮𝗹𝗲, 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝘆, 𝗮𝗻𝗱 𝘁𝗿𝘂𝘀𝘁. Let’s stop obsessing over prompts And start engineering for 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗲. #AgentBuildAI #AgenticAI #AIAgents #LLMops #EnterpriseAI #AIArchitecture

Your AI system is only as secure as its weakest layer. Most teams protect one layer. Think they're done. They're not. 🚨 Here are 22 steps across 6 critical layers that separate a secure AI stack from a breach waiting to happen 👇 🛡️ DATA SECURITY FOUNDATION ① Classify sensitive data before AI ingestion ② Enforce RBAC / ABAC access controls ③ Encrypt everywhere - rest, transit, inference ④ Mask & tokenize before prompts or logs 🛡️ PROMPT & INPUT SECURITY ⑤ Validate every user input - filter injection payloads ⑥ Block prompt injection with active guardrails ⑦ Restrict agent tool permissions to approved workflows only ⑧ Isolate session memory - zero cross-user leakage 🛡️ MODEL LAYER PROTECTION ⑨ Deploy in isolated, authenticated VPC environments ⑩ Version, track, and rollback models with approval workflows ⑪ Audit training data for poisoning, bias, compliance ⑫ Protect APIs - authentication, rate limiting, full logging 🛡️ OUTPUT & DECISION VALIDATION ⑬ Moderate outputs before delivery - catch unsafe responses ⑭ Verify facts against trusted enterprise knowledge ⑮ Embed policy controls directly into response pipelines ⑯ Require human approval for high-risk decisions 🛡️ MONITORING & OBSERVABILITY ⑰ Detect model drift - track performance degradation ⑱ Flag behavioral anomalies and suspicious automation ⑲ Log every prompt, output, and tool call ⑳ Quantify the financial risk of AI failures 🛡️ GOVERNANCE & COMPLIANCE ㉑ Map controls to GDPR, EU AI Act, ISO 42001, SOC 2 ㉒ Establish a cross-functional AI governance council 22 steps. 6 layers. One complete secure AI stack. Miss one layer and the other five don't fully protect you. That's not opinion. That's how security architecture works. Build this before you ship to production. Not after the breach teaches you why you should have. Which step is your team currently weakest on? Drop it below 👇 Save this - the AI security checklist every engineering team needs pinned. Repost for every developer and security leader building AI in production. Follow Vaibhav Aggarwal For More Such AI Insights!!

Today, AI agents derive their power from processing external data. Processing emails, parsing user forms, and grounding answers with live search or reading the open web. This opens a massive attack surface: Indirect Prompt Injection (IPI). Attackers poison the data an agent reads. 📍 They embed malicious commands in webpages or emails. When ingested, the agent is hijacked—its "data" becomes "instructions." ❌ Probabilistic "99% accurate" guardrails are a misnomer. An attacker only needs a 1% chance of success to win. The core issue is twofold: 1. The Data Pipeline is Too Big. It's impossible to secure all untrusted data pipelines. Your agentic tools are ingesting untrusted data from the open web, emails, and user uploads. Each one is a vector to defend, all the time. 2. LLMs Are the Wrong Tool for This Job: We are asking a single LLM to both creatively process data and act as a deterministic security enforcer. This is an architectural flaw. An LLM, by its very design, blends context and finds patterns. It is not built to deterministically separate a "piece of data" from an "instruction." And we see a constant stream of novel jailbreaks. Attackers will always find new ways to bypass guardrails. I recently came across an excellent whitepaper from Google DeepMind that proposes an elegant, secure-by-design architecture called CaMeL. (CApabilities for MachinE Learning) https://lnkd.in/gbM6dgwf The core principle is simple but powerful: Strictly separate Control Flow from Data Flow. Instead of one giant, all-powerful agent, the CaMeL model splits the work into three distinct components: 1️⃣ Q-Agent (Quarantine): This is the "receiving dock" that quarantined & sandboxed. It's the only part of the agentic system that touches untrusted data (from the web, emails, forms). Its sole job is to sanitize, structure, and label this data. It is incapable of calling tools. 2️⃣ P-Agent (Privileged): This is the "planner" and only reads the sanitized, structured data from the Q-Agent. Its job is to analyze the data and create an execution plan (e.g., "call send_email tool with this text"). 3️⃣ CaMeL Interpreter (Security Rules Processor): This is the "enforcer." It's a deterministic rules engine. It takes the plan from the P-Agent and checks it against a security policy before any tool is ever executed. This architecture lets you operationalize security. Instead of "hoping" the LLM behaves, you prove it will with hard-coded rules based on threat models: DENY if data.source == 'web' and plan.action == 'file_write' DENY if data.source == 'email_body' and plan.action == 'send_email' The LLM (P-Agent) proposes an action. The Interpreter enforces the policy. This shifts the paradigm, secure-by-chance to secure-by-default. Threat modeling deterministic guardrails for every tool is admittedly complex, but for high-stakes agentic workflows, it is a viable path forward. #AgenticAI #AISecurity #IndirectPromptInjection #IPI #Guardrails