AGNTCon Preday: Agentic AI in the Wild — Securing What Runs in Production

On the evening of 16 September I went to the AGNTCon Preday Meetup at Adyen’s office on the Rokin in Amsterdam, the night before AGNTCon + MCPCon Europe opened at RAI. The banner on the screens read “Agentic AI in the Wild: Securing What Runs in Production”. There were three talks (Qodo, Snyk and Postman) and a panel.

Different communities, same agents

The opening slide was titled “Different communities, same agents”: “Java, cloud native, APIs, security, code quality. Separate rooms until tonight, and the overlap on agentic engineering is now enormous. Co-hosted, not sponsored.” The communities it listed were AmsterdamJUG, the Qodo Dev Community, Dutch Cloud Native & AI and WeMakeDevs. The companies on stage were Snyk, Qodo, Microsoft, Elastic, Postman and Adyen. Adyen got a thank-you slide “for the room on Rokin, the food and the drinks”.

The agenda

• 18:00: Doors open, drinks and networking
• 18:30: Welcome and opening remarks
• 18:40: Nnenna Ndukwe (AI Developer Relations Lead, Qodo)
• 19:00: Break, food and networking
• 19:15: Panel: Agentic AI in the Wild
• 19:55: Break, food and networking
• 20:10: Liran Tal (AI Security Researcher & Developer Advocate, Snyk)
• 20:30: Gbadebo Bello (Senior Developer Advocate, Postman)
• 20:50: Closing remarks

The job titles above are the ones on each speaker’s own slides.

Qodo: Verification Gates for Agentic Engineering

Nnenna Ndukwe (AI Developer Relations Lead, Qodo) opening “Make Quality Enforceable: Verification Gates for Agentic Engineering”.

Nnenna Ndukwe’s talk was “Make Quality Enforceable: Verification Gates for Agentic Engineering”. It wasn’t a pair-programming pitch. It was about where code-quality rules live and how they get enforced when agents write most of the code.

She started with a slide called “We’re building workarounds…”. On the AI code generation side it listed AGENTS.md, agent skills, Claude Code, Cursor, MCPs and context engineering. On the AI code review side it asked “What do we need to prioritize checking for?”, “Noise vs signal” and “How does this scale across distributed teams???”. One example of the workaround tooling was GSD, shown as “a meta-prompting, context engineering and spec-driven development system for Claude Code”, at 55.2k GitHub stars on the slide.

Her answer was “A Verification Layer for Agentic Engineering”, built in three steps:

1. Define what code quality means to you.
2. Decide where the quality standards live.
3. Integrate the verification process where you already work: agents plus agent harness, and your dev workflow (IDE, CLI, CI/CD).

“Step 1 and 2 is all Context Engineering”: every standards document is context.

The slide I’d keep was “Step 1 and 2 is all Context Engineering”: agent.md, Claude.md, engineering standards, internal documentation, code review criteria, org-specific policies and quality expectations all equal context. Then “Operationalize Context” split that context three ways: planning (prompt engineering plus enforced agent skills), code generation (agent skills) and code review (“checks against your rules and standards with adversarial agents”).

She made it concrete with “Example: Qodo’s Review Standards”, a rules screen with entries such as “Always check return values of critical API calls”, “Always provide status_code when raising HTTPException” and “Annotate FastAPI route handler parameters with Python types”, each tagged with a category such as Correctness, Reliability or Quality. The next slide showed a set of audit skills: Audit Dead Code (“dead code, stale flags, and orphans”), Audit Abstractions, Errors Audit, TDD + BDD, Workflow Invariants and a Qodo PR Resolver. She finished with a Qodo + Codex plugin, “The Qodo Agentic Toolbox”, with skills for codebase knowledge, local review before you push, and resolving review findings.

The closing checklist: a centralised context plane feeding agents, local verification, then automated review in CI.

Her “AI Dev Workflow Checklist for Quality”:

1. Define code quality standards.
2. Decide where codified code quality lives: a centralized context plane.
3. Agents and skills pull from that context plane for planning and code generation.
4. Verify local code changes before the PR (CLI, IDE), plus linters and tests.
5. Automate code reviews in CI/Git during the PR.
6. Bonus: automation plus AI for iterative refinement of skills and rules.

My take: this matches the “skills first” talk Adyen gave in the same room the night before, at the ClickHouse meetup: let the agent reason, but keep the rules in one place and make them checkable. Most of the teams I work with have the rules. They’re just scattered across wikis, linters and reviewers’ heads, so no agent can find them.

Panel: Agentic AI in the Wild

The 19:15 panel: “No vendor pitches. What happens when an agent has real access to your systems, and where each team draws the line on trust.”

The panel slide set the brief: “No vendor pitches. What happens when an agent has real access to your systems, and where each team draws the line on trust.”

Moderator: Dana Fine (Global Open Source & Community Manager, Qodo)

Panelists, as listed on the slide:

• Brian Vermeer (Developer Advocate, Snyk)
• Carlos Mestre del Pino (Cloud Solution Architect, Microsoft)
• Risto Leesmae (Developer AI Experience Lead, Adyen)
• Carly Richmond (Principal Developer Advocate, Elastic)

I didn’t take notes on the discussion itself, so I won’t put words in the panelists’ mouths.

Snyk: Your AI Agent Installed Malware Because a SKILL.md Told It To

Liran Tal (AI Security Researcher & Developer Advocate at Snyk, per his closing slide) gave the security talk of the evening: “Your AI Agent Installed Malware Because a SKILL.md Told It To”, subtitled “weaponizing AI agents reasoning before pulling the trigger”.

He opened with a riddle: what do you call software that accepts instructions via Telegram, has full control of and access to your machine, reads your emails, controls your browser and installs third-party plugins to extend itself? The slide answered “A Trojan OpenClaw”.

Liran Tal’s OpenClaw slide: skills from a public registry, full permissions, and “one bad skill”.

The OpenClaw slide made the threat model explicit. OpenClaw is an open-source AI assistant that lives on your machine and uses skills from a public registry called ClawHub:

• Skills: third-party capability plugins from a public registry. No review, no signing.
• Full permissions: every skill inherits the agent’s shell, filesystem, network and messaging access.
• One bad skill: a single compromised skill equals total control over the agent and everything it touches.

From there he went through “The Lethal Trifecta” (private data, untrusted content, external communications) and the scale of the problem: 1,493,492 skills published on Vercel’s Skills.sh registry, with the aside that “it took npmjs 10 years to pass 1 million packages”. His “But Worse” slide explained why this is worse than the npm problem:

• Higher privilege: skills inherit full agent permissions.
• Prompt injection: natural language evades code scanners.
• Untracked: skills sit in .claude/ and ~/.claude directories.
• No lockfiles: no version pinning and no integrity checks.

And the barrier to entry? One Markdown file, with zero signatures required, zero security reviews and zero sandboxing.

The three takeaways, ending with a free scanner command.

His key takeaways:

1. Agent Skills are a software supply chain. Treat them with the same rigor as npm/PyPI packages.
2. The agent is the social engineer. Your agent is the phishing vector.
3. Scan your skills today. Run uvx snyk-agent-scan@latest --skills. It’s free and takes seconds. “Regex-based scanning is not enough.”

My take: “the agent is the phishing vector” is the sentence I’d put in front of a security team. We spent a decade teaching people not to run what an email tells them to. A skill file is that email, read by something with shell access that doesn’t hesitate. Pin and review skills like dependencies, and keep agent permissions narrower than the developer’s own.

Postman: Your API Gateway Wasn’t Built for AI Agents

Gbadebo Bello (Senior Developer Advocate and AAIF Ambassador, per his intro slide) closed the evening with “Your API Gateway Wasn’t Built for AI Agents”.

His starting point: “API Gateways were designed two decades before the Agentic era.” A classic gateway (load balancing, TLS termination, authentication, protocol translation, caching, rate limiting) works because API gateways are reverse proxies, clients are deterministic and routes are pre-determined. An agent breaks all three assumptions.

“The Operational Problem” showed one AI application talking directly to LLMs (OpenAI, Anthropic, Gemini), MCP servers, internal REST/GraphQL/gRPC APIs and other agents over A2A, each with its own credentials, auth, rate limits, protocols and logs. “Direct integrations create security, governance, reliability, and visibility challenges at scale.” He then grouped the questions every gateway tries to answer (governance, security and identity, traffic and routing, observability) and asked: what if one programmable enforcement layer sat in the execution path of all of them?

“The Evolution of Gateways”: from governing endpoints to governing the agent’s interactions across all of them.

“The Evolution of Gateways” put it in one line each: an API gateway governs endpoints, an LLM gateway governs models, an MCP gateway governs tools, and an agent gateway governs the agent’s interactions across all of them. The comparison table that followed was titled “Agent Gateways Govern INTENT”: the primary object moves from endpoints to models to tools to intent, and the client from a deterministic app to a probabilistic app to an AI agent to an autonomous system.

The old question and the new one.

The slide that summed it up was “From Managing Requests to Governing Intent”. The old question, for request management: “Is this client allowed to call this endpoint?” The new question: “Is this agent allowed to take this action, with this tool, using this identity, in this context?” That means enforcing policy “at the consequence boundary”, by analysing tools, LLM outputs and active execution traces.

He spent a slide on agent identity as “an unsolved operational problem”: traditional API security relies on a clear identity chain, but agents acting for a user exchange credentials across shared infrastructure and invoke other agents recursively, “leading to untrustworthy delegation chains”. His proposed fix is a gateway that establishes trusted identity, propagates user context and narrows access scopes per step. The talk ended with Postman Fabric Gateway, which “sits between agents and everything they need, providing a single, governed path for all interactions” over HTTP, gRPC, MCP and A2A, and a short live demo of its console with an MCP route configured.

My take: the four-gateway slide is a useful map even if you never buy one. Most platforms I see already run an API gateway and have bolted on an LLM proxy. The MCP and agent layers are where policy is still missing, and identity propagation across agent hops is the hard part. The same theme came back the next day at AGNTCon, in Solo.io’s agentgateway keynote and the delegated-authorization talk, both in my Day 1 recap.

Related

• AGNTCon + MCPCon Europe 2026: Day 1 recap
• ClickHouse Amsterdam Meetup @ Adyen: AI Agents Meets Real-Time Analytics
• Qodo: open source AI code review
• Snyk AI security meetup Amsterdam 2026