Context Engineering for AI Agents Has a Security Gap, and It's Hiding in Skills

Most teams that are serious about context engineering for AI agents have already moved past stuffing everything into a single system prompt. They're writing CLAUDE.md files, building reusable skills, and handing their coding agents structured guidance instead of hoping the model figures things out on its own. What's less settled is whether that guidance is safe to run.

That's the question Krzysztof Huszcza has been living with. He leads AI security incubation at Snyk, the application security company that's spent the past decade getting developers to own security earlier in the pipeline. He joined Simon Maple for a special live stream with Tessl to talk through what happens when the artifacts developers use to steer their agents become a new kind of software supply chain.

Skills are the new context engineering artifact, and they shipped without a scanner

Snyk's traditional pitch to developers was straightforward: shift security left, close the loop between finding a vulnerability and fixing it, and stop treating security as something that blocks a pull request at the last minute. That model worked because the artifact in question, code, already had decades of tooling built around it.

Skills don't have that. A skill, Huszcza explained, is "partially the file, the MD file that gives instruction to the agent," but skills can also contain code. That dual nature is what makes them hard to secure with existing tools. A traditional scanner can look at the code half of a skill and flag something obviously malicious. It has no idea what to do with a paragraph of English that quietly tells an agent to exfiltrate credentials.

Huszcza's team put that gap to the test earlier this year with a piece of research they call ToxicSkills. Around the same time OpenClaw was exploding in popularity and skills were flooding into ClawHub, Snyk analyzed what the community was actually publishing. They found roughly 76 skills carrying purely malicious code, plus a separate set that contained prompt injection payloads designed to hijack an agent's context rather than exploit its runtime.

What makes a skill risky, in one line: a skill is risky when either its code executes something harmful, or its natural-language instructions can override the agent's actual task, and most scanners today only check for the first one.

The prompt injection half is the harder problem. Agents, Huszcza noted, are not very good at distinguishing between an instruction from their user and context that arrived from a third party. If an attacker manages to get injected text into that context, in a skill, a web search result, a piece of retrieved documentation, they can potentially redirect the agent to exfiltrate credentials from its own environment. Catching that requires a fundamentally different kind of tool, something closer to a classifier trained to recognize manipulative natural language than a conventional static analyzer.

AI agent context management gets harder once the skill is your own developer's

Third-party skills are the obvious worry. It's the enterprise case that's more interesting, because the threat model flips. Huszcza described more and more of Snyk's enterprise customers standing up internal skill registries so platform teams can encode their own paved paths, the approved way to deploy, the approved way to touch production, directly into a skill their developers pull into their agent.

Once the publisher is your own team rather than an anonymous third party, malware stops being the main concern. Huszcza shared an incident from inside Snyk itself: a developer wrote a skill that handed a coding agent production credentials with far more standing access than it needed. "These credentials were not just in time, nicely injected," he said. "They were overly permissive." Nothing about it went through a paved path, and it went unnoticed until the security team caught wind of developers using it. That's not a story about someone downloading malware. It's a story about a well-intentioned internal tool that quietly expanded the agent's blast radius.

MCP servers, skills, and what a secure-by-default agent stack requires

This is the throughline connecting Tessl and Snyk's integration: every skill and MCP server added to the Tessl registry now gets scanned automatically, and that scan is tied to a specific version rather than the skill as a whole. Huszcza flagged version drift as its own risk. A developer can vet a skill once, then unknowingly pull down an updated version later that behaves very differently. Attaching the scan to each version, rather than treating the skill as a single static thing, closes that gap.

Huszcza was candid that nobody in this space has a complete answer yet. The practices he described are closer to habits than a finished framework: scan third-party skills before installing them, and just as importantly, scan the skills you write yourself before you share them, since a security scanner can surface issues, such as an unscoped credential or a missing guard against prompt injection, that you can then hand back to your agent to fix.

Snyk's next move, under a product line it calls Evo, extends that thinking across three layers: visibility into which skills and MCP servers developers are actually using across an organization, security checks on the code an agent generates as it works, and, in a capability aimed for general availability in the third quarter, guardrails on agent behavior itself, catching credential leaks or prompt injection attempts as they happen rather than after the fact.

Huszcza's closing advice was simple enough to fit on a sticky note: "don't go YOLO." Sandbox what you can, don't auto-approve everything an agent asks for, and check your skills before you trust them. The tooling to make that easy is still catching up. Treating skills and context with the same scrutiny teams already apply to open source dependencies is, for now, the best defense available.