{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifebvddv3rcrcbwfqlpx4veakdb2vfqtzebgcmlmwmgoeccch3l6q",
    "uri": "at://did:plc:jvtquacwpds4pvrhh2k4l3ft/app.bsky.feed.post/3mmf3pillqog2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicmj3d4ptdolpe3eerribqog42frlwe6yoo5vge45ncela6kks24q"
    },
    "mimeType": "image/jpeg",
    "size": 83992
  },
  "path": "/blog/agentic-ai-is-securitys-next-blind-spot-because-it-can-act/",
  "publishedAt": "2026-05-21T18:52:44.456Z",
  "site": "https://www.kylereddoch.me",
  "tags": [
    "The Hacker News",
    "careful adoption of agentic AI services",
    "cross-prompt injection",
    "security best practices",
    "80% of Fortune 500 companies use active AI agents",
    "software and AI agent identity and authorization",
    "4.5x more security incidents",
    "agentic risk guidance"
  ],
  "textContent": "> Agentic AI is not scary because it can write a better paragraph than a chatbot from two years ago. It is scary because it can read, decide, click, call tools, remember context, and take action inside systems we already struggle to secure.\n\nI have been thinking a lot about a recent piece in The Hacker News that frames agentic AI as security’s next blind spot. I agree with the core idea, but the part that really sticks with me is not the “AI” part.\n\nIt is the **blind spot** part.\n\nSecurity teams have a long history of arriving late to the thing the rest of the business already adopted. Cloud was like that. SaaS was like that. Browser extensions were like that. Shadow IT was absolutely like that. The first phase is always the same: people find a useful tool, the tool makes work easier, adoption spreads faster than governance, and security gets pulled in after the architecture, access model, and business expectations are already set.\n\nAgentic AI is following that pattern, but faster.\n\nThe difference is that this time the tool is not just storing data or presenting an interface. It can act.\n\n## This is not just chatbot risk anymore\n\nThe older generative AI security conversation was already messy enough. Teams had to think about sensitive data in prompts, model outputs, hallucinations, policy, vendor terms, and users pasting things into tools they should not have been using for work.\n\nAgentic AI adds a new layer.\n\nAn agent is not only answering a question. It may be reading from a ticketing system, querying a database, searching files, calling an API, drafting an email, opening a pull request, updating a calendar, running a command, or handing work to another agent. The joint Five Eyes guidance on careful adoption of agentic AI services describes these systems as LLM-based agents combined with tools, external data sources, memory, and planning workflows that can operate without continuous human involvement.\n\nThat is a different security animal.\n\nA chatbot can give a bad answer. An agent can give a bad answer and then do something with it.\n\nThat is why I think the industry needs to stop treating agentic AI as a normal software rollout with a slightly weirder interface. The risk is not only whether the model says something wrong. The risk is whether the system has enough access to turn a wrong answer, poisoned instruction, or manipulated workflow into a real action.\n\n## The old boundaries get blurry fast\n\nTraditional application security depends on boundaries that are at least somewhat understandable:\n\n  * this user has these permissions\n  * this service account can call this API\n  * this app writes to this database\n  * this workflow requires this approval\n  * this log shows who did what\n\n\n\nAgentic AI puts pressure on all of those assumptions.\n\nAn agent may act on behalf of a person, but it is not the person. It may call tools through a platform, but it is not the platform. It may read a web page, a document, an email, a Slack message, a Jira ticket, or a calendar invite and treat that content as context for its next action. It may keep memory across sessions. It may chain multiple tools together in a way no single human would have done manually.\n\nThat creates a weird accountability problem. When something goes wrong, who actually did it?\n\nWas it the user who gave the initial prompt? The agent that interpreted it? The tool that executed the API call? The developer who wrote the system prompt? The vendor that shipped the connector? The business unit that approved the workflow? The security team that never saw it until after the fact?\n\nThe Five Eyes guidance calls this out directly: agentic architecture can make it harder to trace why an action happened because decisions may be spread across planning, retrieval, execution, and other components. That is not a philosophical problem. That is an incident response problem.\n\nIf you cannot answer “what happened, why did it happen, what identity did it use, what data did it touch, and what else could it have done?” then you do not have a controlled system. You have a mystery with an API token.\n\n## Prompt injection becomes an access problem\n\nPrompt injection has been discussed so much that people are starting to tune it out, which is unfortunate because the agentic version is much more operationally serious.\n\nThe simple version is this: models still struggle to keep instructions and data cleanly separated. Microsoft describes the risk in its own agentic Windows documentation, warning that cross-prompt injection can happen when malicious content embedded in UI elements or documents overrides agent instructions and leads to unintended actions like data exfiltration or malware installation.\n\nThat is not just a clever prompt trick. It is an access control failure waiting to happen.\n\nImagine an agent that can read email and create tickets. A malicious email tells it to ignore prior instructions and file a fake urgent support request. Annoying, but maybe contained.\n\nNow imagine an agent that can read email, access a knowledge base, query customer data, create tickets, and trigger a remote management workflow. The same class of attack has a very different blast radius.\n\nThe prompt is not the vulnerability by itself. The vulnerability is the combination of untrusted input, trusted tool access, broad permissions, and an agent that can bridge systems that were not meant to trust each other.\n\nThat is why “we have a prompt filter” does not make me feel warm and fuzzy. Prompt filters can help, but they are not a substitute for real permission boundaries. If an agent can be tricked, the damage should still be boring, narrow, logged, reversible, and easy to understand.\n\n## MCP is useful, and that is exactly why it matters\n\nThe Model Context Protocol has become one of the big pieces of this conversation because it gives agents a standard way to connect to tools and data sources. That is useful. It also means MCP servers, connectors, scopes, tokens, and local runtimes become part of the security boundary.\n\nThe official MCP security best practices already read like a reminder that this is not a toy integration layer. They cover risks like confused deputy problems, token passthrough, SSRF, session hijacking, prompt injection through sessions, and local MCP server compromise.\n\nThat should get every defender’s attention.\n\nThe security issue is not that MCP exists. Standards can be good. The issue is that a standard way to connect agents to tools also becomes a standard place where bad assumptions can scale.\n\nIf an employee installs a local MCP server from a random repository, what does it have access to? If a coding agent gets a GitHub connector, is it read-only or can it push changes? If an agent can reach both a file system and an external messaging tool, can it be tricked into moving data from one to the other? If a connector asks for broad OAuth scopes because that is easier for the vendor, who is reviewing that?\n\nThose are not future questions. They are current questions.\n\n## The real blind spot is identity\n\nThe part I keep coming back to is identity.\n\nMost organizations already have too many human accounts, too many service accounts, too many stale groups, too many over-permissioned roles, and too many secrets nobody wants to rotate because something important might break. Agentic AI lands directly on top of that mess and adds a new category of actor.\n\nMicrosoft’s security blog says more than 80% of Fortune 500 companies use active AI agents built with low-code or no-code tools, and it argues agents should be held to the same standards as employees or service accounts. That is the right framing.\n\nAn agent needs an identity.\n\nNot just “Kyle used the agent.” Not just “the automation ran.” Not just “the API key worked.” A real identity with ownership, purpose, scope, expiration, logs, and revocation.\n\nNIST’s NCCoE has been looking at this through its concept paper on software and AI agent identity and authorization, which focuses on the risks of giving agents access to tools, applications, and data without the right identification and authorization controls. That is where this conversation has to go.\n\nIf an agent has no distinct identity, you cannot govern it cleanly.\n\nIf you cannot govern it cleanly, you cannot revoke it cleanly.\n\nIf you cannot revoke it cleanly, you are going to have a bad day when it misbehaves, gets compromised, or quietly keeps running long after the person who created it moved on.\n\n## Over-permissioned agents are going to hurt people\n\nThis is where the risk stops being abstract.\n\nTeleport’s 2026 research says organizations with over-privileged AI systems reported a much higher incident rate than organizations that limited AI to only the access needed for the task. The vendor’s own summary says over-permissioned AI systems were associated with 4.5x more security incidents, and 70% of security leaders said AI systems had more access than a human in the same role.\n\nEven if you treat vendor research with the usual caution, the direction is completely believable.\n\nLeast privilege is hard with humans. It is harder with service accounts. It may be even harder with agents, because people are going to over-scope them in the name of usefulness.\n\nThat is the tradeoff everyone wants to dodge. The more an agent can access, the more impressive the demo. The narrower its permissions, the more often it has to stop and ask for help. Business teams want the magic. Security teams have to care about the blast radius.\n\nBoth sides are going to have to get more honest.\n\n  * An agent that can summarize public web pages does not need access to your email.\n  * An agent that triages support tickets does not need write access to your code repositories.\n  * An agent that drafts calendar responses does not need terminal access.\n  * An agent that helps with incident notes should not be able to disable controls, rotate credentials, or make infrastructure changes without a human approval step that actually means something.\n\n\n\nThis is basic security, but agentic AI makes basic security easier to forget because the interface feels conversational and helpful.\n\n## Why this is especially messy for MSPs\n\nThe MSP angle worries me because MSPs already sit in a strange trust position. One provider may have access to many clients, many tenants, many admin portals, many remote management tools, many documentation systems, and many ticketing workflows.\n\nNow add agents.\n\nAn MSP technician using an AI assistant to summarize tickets is one thing. An MSP technician using an agent that can read tickets, search documentation, open admin portals, draft customer emails, run scripts, and interact with an RMM platform is something else entirely.\n\nThat agent may be useful. It may save time. It may reduce repetitive work. It may help a small team keep up.\n\nIt may also become a new privileged operator sitting inside the exact workflow attackers already want to abuse.\n\nThe risk is not only a science-fiction scenario where the agent “goes rogue.” The boring scenarios are enough:\n\n  * a poisoned ticket comment influences the agent’s next action\n  * a malicious customer email gets treated as trusted operational context\n  * an over-scoped connector exposes documentation from the wrong client\n  * an agent uses a technician’s broad permissions instead of a narrower task identity\n  * a helpful automation makes a change across multiple tenants before anyone notices the premise was wrong\n\n\n\nThat is the kind of problem MSPs cannot afford to hand-wave. Cross-client trust is fragile. Agentic AI can make that trust more efficient, but it can also make mistakes and abuse scale faster.\n\n## What I would do before approving agentic AI in a real environment\n\nI do not think the answer is “ban it all.” That will fail in the same way every broad shadow IT ban fails. People will use tools that help them do their jobs.\n\nThe better answer is to make the first approved path safer than the unofficial path.\n\nHere is where I would start.\n\n### 1. Build an agent inventory\n\nYou cannot secure what you cannot name. Track every approved agent, who owns it, what business process it supports, what model or platform it uses, what data sources it reads, what tools it can call, what identity it runs under, and when it expires.\n\nIf that sounds boring, good. Boring governance is how you avoid dramatic incidents.\n\n### 2. Treat every agent like a non-human identity\n\nAgents should have distinct identities where possible, not shared API keys buried in a connector nobody owns. They should have least privilege, short-lived credentials, clear ownership, and revocation paths.\n\nIf an agent is important enough to act in production, it is important enough to appear in identity governance.\n\n### 3. Separate read, suggest, and act\n\nDo not jump from “summarize this” to “go do it” in one permission tier.\n\nReading data, drafting a recommendation, and taking action should be separate capability levels. The approval path for a read-only research assistant should not look like the approval path for an agent that can modify infrastructure, send external messages, or change customer records.\n\n### 4. Put human approval at the point of impact\n\nHuman-in-the-loop only matters if the human sees the actual action, the target, the data involved, and the consequence.\n\n“Approve this plan” is weak if the plan hides the meaningful details. “Approve sending this exact email to this recipient with these attachments” is better. “Approve running this script against these devices in this tenant” is better. The approval needs to sit where the risk lives.\n\n### 5. Log tool calls like you expect to investigate them\n\nSecurity teams do not need a vague transcript that says the agent “helped with a task.” They need action-level logs: tool invoked, identity used, parameters passed, data touched, external destination, approval gate, result, timestamp, and correlation back to the user or workflow.\n\nMicrosoft’s agentic risk guidance emphasizes actions, tools, outcomes, auditability, and post-execution logs for a reason. Without that, incident response becomes guesswork with nicer branding.\n\n### 6. Treat memory as a security boundary\n\nLong-lived memory is powerful, but it is also a place where bad context can persist. If an agent remembers the wrong thing, stores sensitive data, or carries poisoned instructions forward, the failure can survive beyond one session.\n\nMemory needs governance: what can be stored, who can inspect it, how long it lives, how it is cleared, and what sources are allowed to influence it.\n\n### 7. Red-team the workflow, not just the prompt\n\nTesting one prompt is not enough. Test the whole chain.\n\nWhat happens if a malicious instruction appears in an email? A PDF? A web page? A ticket comment? A calendar invite? A tool response? A repository README? A customer-provided log file?\n\nThe question is not “can the model be tricked?” It can. The better question is “when it is tricked, what can it actually do?”\n\n## My take\n\nAgentic AI is going to be useful. I am not interested in pretending otherwise. Security teams will use it. MSPs will use it. Developers will use it. Business teams will build small agents for workflows security may not even know exist yet.\n\nThat is exactly why this has to be taken seriously now.\n\nThe blind spot is not that security people have never heard of AI agents. The blind spot is that many organizations are still trying to fit agents into old categories: chatbot, automation, SaaS feature, browser assistant, workflow helper, service account.\n\nAgents are a little bit of all of those, and that is the problem.\n\n  * Software that can reason over messy input.\n  * Identities that can touch data.\n  * Automation that can call tools.\n  * Users that do not think like users.\n  * Supply chain dependencies with memory and permissions.\n\n\n\nThat combination deserves its own security model.\n\nFor defenders, the practical move is not panic. It is fluency. Build a small agent. Break a small agent. Connect one to a harmless tool and watch what actually happens. Read the logs. Look at the permissions. Try to inject bad instructions through a document or tool response. See where your assumptions fall apart.\n\nSecurity cannot govern agentic AI from a distance. The teams that understand how these systems are built will be able to ask better questions, design better controls, and become useful partners instead of late-stage blockers.\n\nThe teams that do not will get pulled in later, after the agents are already working, already connected, already trusted, and already hard to unwind.\n\nWe have seen that movie before.\n\nThis time, the software can act on our behalf.\n\nThat should be enough reason to pay attention.",
  "title": "Agentic AI Is Security's Next Blind Spot Because It Can Act",
  "updatedAt": "2026-05-21T18:15:00.000Z"
}