Tips to Secure Agentic AI Systems

Cloud Security Alliance published a framework for securing AI agent identities last year and most orgs still haven't caught up. I've been revisiting this report and it's more relevant now than when it dropped. With 60% of enterprises deploying agents this year and 78% still lacking formal AI identity policies, the gap is only getting wider. Here's what stood out: 1️⃣ Your IAM stack wasn't built for this: OAuth, SAML, and OIDC assume a human is in the loop. AI agents authenticate up to 148x more frequently than humans and chain actions across systems autonomously. Static credentials break down when agents delegate to other agents. 2️⃣ Agent identity needs to go beyond API keys: The report makes a strong case for Decentralized Identifiers and Verifiable Credentials, cryptographically verifiable, dynamically scoped, and revocable in real time. 3️⃣ Zero Trust is the baseline, not the stretch goal: Never trust, always verify, and assume breach. Map agent-to-agent interactions with dynamic trust scoring. Every delegation needs independent verification. 4️⃣ The delegation gap is a liability: When Agent A delegates to Agent B, who's accountable? Most orgs can't answer that. The confused deputy problem at scale is a real governance risk this framework directly addresses. If your GRC team hasn't mapped how AI agents get credentialed, scoped, and monitored, save this as a resource for your next AI risk assessment! Download the full report here: https://lnkd.in/gx8G5CJg #AIGovernance #GRC #AgenticAI #IdentityManagement #AIRisk

Most enterprises deploy AI Agents. Few secure them. That gap is where attackers are already operating… Agents introduce a new attack surface: autonomous reasoning, tool calls, shared memory, and multi-agent communication. Securing them needs controls across 4 planes, not just the perimeter. Let me break down the 12 controls every AI Agent actually needs: 📌 Identity & Access 1. Identity & Authentication - Give every agent a unique, traceable identity - No shared API keys, full audit logging 2. Least Privilege Access - Scope permissions across data, models, and tools - Grant access only for the active task 3. Tool Call Authorization - Require approval before any tool executes - Control action-level permissions 📌 Data & Memory 4. Memory Isolation - Validate what enters agent memory - Isolate memory across sessions and agents 5. Output & Data Protection - Filter outputs before exposure - Apply DLP policies for sensitive data 6. Prompt Injection Defense - Validate inputs before they shape reasoning - Block indirect injections from external data 📌 Execution Safety 7. Sandboxed Execution - Run agents in isolated environments - Prevent cascading failures across systems 8. Human-in-the-Loop Oversight - Add approval checkpoints for critical actions - Keep humans in control of high-stakes decisions 9. Agent Communication Control - Enforce structured message schemas - Reject malformed agent-to-agent messages 📌 Monitoring & Audit 10. Continuous Monitoring - Track reasoning and tool usage in real time - Set behavioral baselines to detect anomalies 11. Audit Trails - Log every action with full context - Make decisions traceable for governance 12. Lifecycle Governance - Run regular permission and access reviews - Rotate credentials, update model policies This maps to how OWASP's Agentic AI Top 10, NIST AI RMF, and Gartner categorize agent risk. Secure the brain AND the hands. Controls belong in both planes. If you want to understand AI agent concepts deeper, my free newsletter breaks down everything you need to know: https://lnkd.in/eU4FknKQ Save 💾 ➞ React 👍 ➞ Share ♻️ & follow for everything related to AI Agents

🚨 Agentic AI is powerful… but it’s also expanding your attack surface. Most teams are rushing to build AI agents. Very few are thinking deeply about securing them. That’s a problem. Because vulnerabilities in Agentic AI aren’t theoretical, they’re already exploitable. Here are 7 critical risks every builder should understand: 🔐 Token / Credential Theft Sensitive data exposed via logs or insecure storage. → Easy to exploit. High impact. 🔁 Token Passthrough Forwarding tokens without validation = open door for abuse. → Attackers love this. 💉 Prompt Injection Malicious instructions hidden in inputs. → LLMs will follow them if unchecked. ⚙️ Command Injection Unfiltered inputs triggering unintended system actions. → Critical severity. Often overlooked. 🧪 Tool Poisoning Tampered tools executing hidden malicious logic. → Trust = vulnerability. 🚫 Unauthenticated Access Endpoints without proper auth. → Shockingly common. 💣 Rug Pull Attacks Compromised maintainers pushing malicious updates. → Supply chain risk is real. The takeaway? If your AI agent can: • Access tools • Execute commands • Use credentials • Interact with external systems 👉 Then it must be treated like production infrastructure, not a prototype. 🔧 What you should do next: • Validate every input • Implement strict auth & access control • Sanitize tool usage • Monitor logs (securely!) • Assume adversarial behavior AI doesn’t just introduce new capabilities. It introduces new threat models. And the teams that win will be the ones who build secure AI by design. 💬 Curious, which of these risks are you actively addressing today?

The Cybersecurity and Infrastructure Security Agency, National Security Agency, and other cybersecurity agencies Published “Careful Adoption of Agentic AI Services” providing a detailed framework for securely deploying, operating, and governing agentic AI systems. This joint guidance focuses on the unique risks introduced by AI systems capable of autonomously making decisions, using tools, and taking actions with limited human intervention, and recommends a “secure by default” approach. Some of the recommendations include: • Adopt a phased deployment approach by starting with low-risk use cases, limiting permissions and autonomy initially, and progressively expanding capabilities based on ongoing evaluation and oversight. • Implement strong guardrails and constraints, including explicit “do-not-do” rules, deny lists, safety policies, sandboxing, and layered controls to reduce the risk of harmful or unintended actions. • Maintain meaningful human oversight as a central control mechanism for high-impact or irreversible actions. The document recommends clear human approval checkpoints , defined accountability structures, and escalation procedures for sensitive operations. • Apply strict privilege and authentication controls by limiting agents to the minimum access required, using just-in-time credentials, continuously validating authorization, and preventing agents from modifying their own privileges. • Use continuous monitoring and comprehensive logging to track agent reasoning, tool usage, decisions, identity changes, and anomalous behavior in real time. The guidance stresses that monitoring should extend beyond inputs and outputs to include internal agent processes. • Conduct red teaming and scenario-based testing before and after deployment to identify prompt injection risks, emergent behaviors, attempts to evade safeguards, and other unexpected system interactions. • Strengthen resilience through fail-safe defaults, rollback capabilities, segmentation, and containment mechanisms designed to reduce the operational impact of compromised or malfunctioning agents. • Manage third-party and tool-integration risks by verifying external components, restricting tool usage to approved allow lists, monitoring inter-agent interactions, and applying supply chain risk management practices. • Integrate governance and accountability structures that define risk ownership, establish AI-specific policies, and align agentic AI oversight with existing cybersecurity and risk management frameworks. • Use system-level security analysis rather than evaluating components in isolation. The document highlights that risks in agentic AI environments often emerge from interactions between models, tools, humans, datasets, and infrastructure. The document presents agentic AI security as an ongoing operational discipline focused on resilience, containment, observability, and controlled autonomy across the full lifecycle of deployment and use. 

𝐀𝐈 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐈𝐬 𝐧𝐨𝐭 𝐎𝐧𝐞 𝐓𝐨𝐨𝐥, 𝐈𝐭 𝐢𝐬 𝐚 𝐒𝐭𝐚𝐜𝐤 Buying one security product and calling your AI "secure" is like locking the front door while leaving every window open. Real AI security is six layers deep: 𝐋𝐀𝐘𝐄𝐑 𝟏: 𝐈𝐃𝐄𝐍𝐓𝐈𝐓𝐘 𝐀𝐍𝐃 𝐀𝐂𝐂𝐄𝐒𝐒 Purpose: Control who can access AI systems, models, and data. What it includes: Model APIs, internal AI tools, agent-level permissions. Key controls: - Role-based and attribute-based access - Zero-trust architecture - API authentication No identity layer means anyone or any agent can reach your models. 𝐋𝐀𝐘𝐄𝐑 𝟐: 𝐃𝐀𝐓𝐀 𝐏𝐑𝐎𝐓𝐄𝐂𝐓𝐈𝐎𝐍 Purpose: Safeguard sensitive organizational data before it is used by AI models. What it protects: Personally identifiable information, financial records, internal business data. Key controls: - Data masking - Tokenization - Encryption (in transit and at rest) 𝐋𝐀𝐘𝐄𝐑 𝟑: 𝐏𝐑𝐎𝐌𝐏𝐓 𝐀𝐍𝐃 𝐈𝐍𝐏𝐔𝐓 𝐒𝐄𝐂𝐔𝐑𝐈𝐓𝐘 Purpose: Defend AI models against malicious or manipulated inputs. Risks handled: Prompt injection attacks, data leakage through prompts, jailbreak attempts. Key controls: - Input validation - Prompt filtering - Policy enforcement - Rate limiting This is the layer most teams skip and where most AI-specific attacks happen. 𝐋𝐀𝐘𝐄𝐑 𝟒: 𝐆𝐎𝐕𝐄𝐑𝐍𝐀𝐍𝐂𝐄 𝐀𝐍𝐃 𝐂𝐎𝐌𝐏𝐋𝐈𝐀𝐍𝐂𝐄 Purpose: Ensure AI systems comply with regulations and internal policies. Framework coverage: GDPR, EU AI Act, ISO 42001. Key controls: - Audit logging - Risk classification - Decision traceability - Policy enforcement 𝐋𝐀𝐘𝐄𝐑 𝟓: 𝐎𝐔𝐓𝐏𝐔𝐓 𝐕𝐀𝐋𝐈𝐃𝐀𝐓𝐈𝐎𝐍 Purpose: Verify AI-generated responses before they are used or acted upon. Risks addressed: Hallucinated outputs, compliance violations, unsafe or harmful responses. Key controls: - Fact-checking mechanisms - Policy validation - Output moderation 𝐋𝐀𝐘𝐄𝐑 𝟔: 𝐌𝐎𝐍𝐈𝐓𝐎𝐑𝐈𝐍𝐆 𝐀𝐍𝐃 𝐎𝐁𝐒𝐄𝐑𝐕𝐀𝐁𝐈𝐋𝐈𝐓𝐘 Purpose: Continuously track AI system behavior in production environments. What it monitors: Usage patterns, response accuracy, model drift, latency. Key controls: - Behavior tracking - Audit logs - Performance monitoring 𝐖𝐇𝐄𝐑𝐄 𝐓𝐄𝐀𝐌𝐒 𝐆𝐎 𝐖𝐑𝐎𝐍𝐆 They invest heavily in Layer 1 (identity and access) and ignore Layers 3 and 5 (prompt security and output validation).  The result is a system that authenticates users perfectly but lets prompt injections and hallucinated outputs through unchecked. 𝐓𝐇𝐄 𝐏𝐑𝐈𝐍𝐂𝐈𝐏𝐋𝐄 AI security is a stack, not a tool.  Six layers, each protecting a different attack surface.  Miss one and the others can not compensate. 𝐇𝐨𝐰 𝐦𝐚𝐧𝐲 𝐨𝐟 𝐭𝐡𝐞𝐬𝐞 𝐬𝐢𝐱 𝐥𝐚𝐲𝐞𝐫𝐬 𝐝𝐨𝐞𝐬 𝐲𝐨𝐮𝐫 𝐀𝐈 𝐬𝐲𝐬𝐭𝐞𝐦 𝐜𝐮𝐫𝐫𝐞𝐧𝐭𝐥𝐲 𝐜𝐨𝐯𝐞𝐫? ♻️ Repost this to help your network get started ➕ Follow Sivasankar Natarajan for more #EnterpriseAI #AgenticAI #AIAgents

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

One of the hardest problems in securing AI agents isn't the AI itself. It's permissions. Traditional applications follow predictable code paths, so you can review the source, identify every API call, and grant exactly what's needed. AI agents don't work that way. They reason dynamically, choose tools at runtime, and operate at machine speed. If you give an agent a permission, you have to assume it will use it, whether you intended it to or not. That's a fundamentally different threat model than most teams are used to designing for.                     I wrote a new post on the Amazon Web Services (AWS) Security Blog that lays out three principles for building deterministic IAM controls around these non-deterministic systems. The first principle is to assume all granted permissions could be used. Design based on acceptable scope of impact, not just intended functionality. The second is to provide organizational guidance on role usage through session policies, permission boundaries, and SCPs so that security doesn't depend on individual developers making the right credential choice. The third is to differentiate AI-driven actions from human-initiated ones using IAM condition keys or session tags, so you can apply different rules depending on whether a human or an agent is behind the request.                                              These patterns apply whether you're running an AI coding assistant on your laptop or deploying agents on Amazon Bedrock AgentCore. The post covers deployment patterns, concrete IAM policy examples, and implementation guidance for both AWS-managed and self-managed MCP servers. If your team is adopting AI agents and you haven't rethought your IAM strategy yet, this is a good place to start. Blog: https://lnkd.in/eZZfTVCe Christopher Rae, Justin Criswell, CISSP, Himanshu Verma, Ryan Orsi, Brian Mendenhall, Jean-François LOMBARDO, Matt Saner #aws #aisecurity

Exactly what I’ve been warning about for months. An estimated 95% of enterprises experimenting with or deploying autonomous AI agents have not implemented identity protections for those agents. This is not a joke. To put all this in context: • These autonomous, “agentic” systems communicate and act without constant human oversight. Without strong identity and authentication controls, there’s no reliable way to distinguish a legitimate agent from a compromised one. Once an attacker controls an agent, they can chain malicious instructions through the entire ecosystem.  • Traditional IAM and machine identity practices weren’t designed for non-human autonomous agents that can act and escalate privileges on their own. When these deployments lack basic protections like PKI for agents, courting disaster. I am the first one to want to play with emerging tech but honestly, there is no need to blindly adopt agenticAI without addressing underlying identity and authentication issues. Without agentic-specific identity controls, we’re going to see more breaches, more lateral compromise, and new attack surfaces that legacy identity systems simply can’t handle. Enterprises need to stop treating AI as just another productivity buzzword and start treating AI identities with serious gravitas. That means a lot more than just basic KYA initiatives. It means • Enforcing binding trusted identities to every agent • Extending authorization controls to agent-to-agent and human-to-agent interactions • Incorporating machine to machine identity management • Modernizing IAM to manage dynamic, evolving AI identities — not just static human credentials • Creating audit trails for agents • Creating kill switches for agents that go rogue and being able to recognize when this happens And more. Don't say you were not warned. #Identity #Cybersecurity #AgenticAI #AIIdentity #MachineIdentity #ZeroTrust #EnterpriseSecurity #CISO https://lnkd.in/evK4kwVX

Let's be real, the secret to Agentic AI working well in businesses is building trust, making sure things are super reliable, and using good systems engineering; it's all about a strong base for these smart agents. Here’s the uncomfortable math: agents fail exponentially. A 10-step workflow at 95% per-step accuracy delivers ~60% end-to-end reliability. That’s not “pretty good.” That’s unshippable for anything that touches money, customers, or compliance. And the worst failures are invisible: - Infinite loops that burn tokens like a financial denial-of-service attack - Silent failures where the API call “succeeds” but the business outcome is wrong - Hallucinated parameters that pass monitoring while breaking reality - Write actions that turn a tiny mistake into a big blast radius The fix is not “better prompting.” It’s an Architecture of Trust: treat agents like unreliable components and wrap them in deterministic framework. Minimum Viable Trust Stack (MVTS): - Strict schemas for every tool input/output - Regression suite (golden datasets) on every commit - Circuit breakers for steps, time, and cost - Incident replay to reproduce failures deterministically - OpenTelemetry traces so you can debug behavior, not vibes Then mature your operating model: - Evals that move from vibes to metrics, judges, simulations, and canaries - Observability that captures decision records and full execution traces - FinOps at span-level so runaway reasoning doesn’t become your cloud bill surprise Reality check: Hyperscalers win on governance and security. Third-party tools win on deep debugging and operational reliability. Most enterprises will land on a hybrid: Hyperscaler runtime + open telemetry piping into specialized platforms. We must stop conflating model intelligence with system reliability. The competitive advantage belongs to those who wrap probabilistic cores in deterministic frame to force business-as-usual outcomes. Build the architecture of trust, or accept that your agents will remain impressive, unscalable liabilities. If you don’t build a trust architecture, your agents aren’t assets. They’re impressive liabilities. https://lnkd.in/g7R7nvXx #AgenticAI #AIEngineering #AIOps #Observability #Evaluation #Evals #OpenTelemetry #LLMOps #AITrust #EnterpriseAI #AIProductManagement #ReliabilityEngineering #ResponsibleAI #FinOps #DigitalTransformation EXL Rohit Kapoor Vivek Jetley Vikas Bhalla Anand Logani Baljinder Singh Anita Mahon Vishal Chhibbar Narasimha Kini Gaurav Iyer Shashank Verma Vivek Vinod Karan Sood Joseph Richart Aidan McGowran Saurabh Mittal Anupam Kumar Arturo Devesa Sarika Pal Adeel J. Pankaj Khera Vikrant Saraswat Wade Olson Puneet Mehra Arun Juyal Sarat Varanasi Naval Khanna Abhay B. Mustafa Karmalawala Akhil Saraf Anurag Prakash Gupta Nabarun Sengupta

AI agents are powerful, but they also introduce a new layer of security risk. Because unlike normal software, an AI agent can read data, make decisions, call tools, trigger workflows, send messages, access files, and sometimes act without direct human input. That means one small permission mistake can become a much bigger business problem. Before deploying an AI agent, every team should ask: What data can it access? What actions can it take? Can it handle malicious prompts? Does it follow least privilege? Who is accountable if it fails? Is there human approval for high-risk actions? How is it monitored after deployment? Can it be shut down instantly? Has the vendor been assessed? Does it comply with the company’s AI policy? These questions matter because AI security is not only about the model. It is about the full operating environment around the agent: Data access. Tool permissions. Approval workflows. Prompt injection protection. Monitoring. Audit logs. Vendor risk. Compliance. Human accountability. The real danger is not just that an agent gives a wrong answer. The bigger risk is when it takes the wrong action with the right permissions. That is why every AI agent needs clear boundaries before it goes live. Start simple: Map the data. Limit the permissions. Test for attacks. Add human approval. Monitor every action. Keep a shutdown option ready. AI agents can create huge productivity gains, but only when they are designed with security from day one. Because in enterprise AI, speed without control is not innovation. It is risk at scale.