Something dropped yesterday that deserves more attention than it's getting.
Security researchers published findings showing that three popular AI agents — the kind being used by thousands of dev and ops teams right now — can be hijacked through GitHub Actions to steal API keys and access tokens. Your credentials. Gone.
When the researchers disclosed this to the vendors, the response was roughly: "That's not a bug. That's how it works."
Working as intended. By design. Known limitation.
Pick your favourite euphemism. The meaning is the same: not our problem.
What Actually Happened
AI agents integrated with GitHub Actions are everywhere now. If your team is using any kind of AI-assisted development or automation workflow, there's a real chance some version of this setup is already running in your pipelines.
The attack works like this: a malicious actor crafts inputs that cause the AI agent to exfiltrate credentials stored in the environment. Because the agent has legitimate access to those credentials (to do its job), and because it's operating in a trusted context, the usual safeguards don't catch it. The agent doesn't know the difference between a legitimate instruction and an attacker-injected one. It just does what it's told.
This is a variant of prompt injection — the class of attacks where you feed malicious instructions to an AI system and it acts on them. Researchers found it in three separate, widely-used tools. They disclosed responsibly. The vendors responded by classifying it as an inherent limitation rather than a vulnerability.
Researchers at The Register covered this on April 19th. It's the kind of story that should be on the radar of anyone who's integrated AI tooling into their workflows.
Why "By Design" Is the Wrong Answer
When a vendor tells you a security flaw is "by design" or "working as intended," they're saying two things.
First: there's no patch coming. No update. No remediation timeline. You own the risk indefinitely.
Second: when something goes wrong, they're not going to be accountable. If your credentials get stolen through this vector, you'll be the one explaining to your clients, your board, or your funders why their data was compromised. Not the vendor.
This pattern isn't new in security, but it's accelerating fast in the AI space. AI companies are racing to ship features. Security is a cost centre. When a researcher finds a vulnerability that would require real architectural work to fix — rather than a surface-level patch — it is genuinely easier to call it a known limitation than to actually fix it.
And here's the structural problem: it works. Most customers don't have the resources to push back. They accept the framing, move on, and stay exposed.
Why Small Orgs Get Hit Hardest
Large enterprises have security teams, procurement reviews, vendor risk assessments, and the market leverage to demand fixes. If a major enterprise told one of these vendors "fix this or we're cancelling," things would move quickly.
You probably don't have that leverage. And you likely don't have a dedicated security person reviewing every AI tool your team adopts.
The compounding problem is shadow adoption. Someone on your team found a useful AI agent six months ago, integrated it into a workflow, and it never went through any kind of security review. That's completely normal for small orgs — it's how you move fast. But it means you may have these exposures right now without knowing it.
There's also a trust problem. Small orgs tend to trust their tools. If the tool is working — no crashes, no obvious errors — there's no signal that something is wrong. An AI agent quietly exfiltrating credentials doesn't throw error messages.
The vendors know all of this. "By design" is a lot easier to say when your customers don't have the resources to audit what's actually happening.
What to Do Right Now
This isn't "stop using AI tools." These tools are genuinely useful and the productivity gains are real. The answer is being deliberate about what access you give them.
Audit what your AI agents can reach. Any AI agent integrated with your GitHub Actions, CI/CD pipelines, or automation workflows has access to whatever credentials are in that environment. Map it out. Credentials have a way of accumulating — tokens, API keys, service account passwords — and most teams have more in their pipeline environments than they realize.
Apply least privilege, aggressively. AI agents should have the minimum permissions required to do their specific job. If an agent needs to read a repository, it shouldn't also have write access to your production environment. Use dedicated service accounts with tightly scoped permissions, not developer credentials.
Treat AI agents like third-party code. They're not magic. They're software running inside your environment with access to your systems. Apply the same skepticism you'd apply to any external library: what does this actually need? What happens if it's compromised? Would you even know?
Don't take vendor characterizations at face value. When a security researcher finds something in a tool you use, vendors have a financial incentive to downplay it. "Low severity." "Requires specific conditions." "Working as intended." Read what the researcher actually found, not just the vendor's response.
Watch for permission creep on updates. When you update an AI tool or add a new integration, check what permissions it's requesting. Tools that started with read-only access have a way of asking for more over time. Each update is an opportunity to review.
The Bigger Picture
What researchers documented yesterday is a symptom of something structural: AI vendors are moving faster than their security posture allows, and they're externalizing the risk to customers. The "by design" response is going to keep happening. More tools, more integrations, more AI agents running in privileged contexts — and more shrugs when researchers find problems.
Small orgs are not equipped to be the last line of defence here. But until vendors face real accountability for these decisions, being deliberate about access control is the most practical protection you have.
This isn't about becoming security paranoid or slowing down AI adoption. It's about making sure the tools you've brought in are working for you, not quietly creating liabilities you don't know exist yet.
Mapping your AI tool access, locking down permissions, and building a quick internal review process for new tools — this is exactly the kind of sprint work we do with teams. A few days of focused effort and you'll have a clear picture of your exposure and a sensible policy going forward. Most teams are surprised by what they find, and relieved by how manageable it is to address.