In-person workshop for technical teams
Develop with AI without handing over the keys to the repository
One working day for development, architecture and security to share the same system: what the assistant may touch, when it must ask, and which checks must stop an unsafe change before merge.
Delivered at your company. For teams already using Cursor, GitHub Copilot or Claude. Available in English or Spanish.
The problem you already have
AI is already inside the SDLC. The controls are still outside.
The team moves faster with Cursor, Copilot or Claude. It has also added new inputs to the process: instruction files that alter agent behaviour, third-party Skills, MCP servers with credentials, and modes that run commands without approval.
The risk does not end with generated code. It starts with everything the assistant reads, installs and can execute, then continues when a pull request looks correct because it compiles.
This workshop turns that problem into concrete decisions. The team learns what to review before enabling a capability, how to limit it, and what evidence to require before accepting the output.
Workshop outcome
Five decisions the team can make without improvising
Every outcome is demonstrated during the day. Recognising a term on a slide is not enough.
- 01
Separate the model from the orchestrator
Identify whether the risk comes from model output or from policy deciding which files, tools and permissions it receives.
Evidence: a trust map of the assistant the team uses. - 02
Audit context, Skills and MCP
Find poisoned instructions, overbroad capabilities and tool descriptions trying to steer the agent.
Evidence: three unsafe artefacts reviewed and a documented decision. - 03
Choose the right autonomy level
Separate reading, editing and execution. Apply ask-first and a deny list where credentials or system impact exist.
Evidence: the agent asks before env, installs and test changes. - 04
Define when generated code is done
Turn risk into a Definition of Done covering unit, golden, smoke, end-to-end, SAST, secrets and dependencies.
Evidence: a reusable definition ready for the project. - 05
Review without reading every line
Focus human review on assertions, CI YAML, lockfiles, project instructions and sensitive code paths.
Evidence: a generated change blocked by a test first seen red.
Use cases
Situations your team will recognise
These are routine decisions once an assistant can work inside a repository.
Context poisoning
A repository file convinces the agent to write unsafe SQL
The instruction looks like another coding convention. The assistant treats it as authority and concatenates query parameters.
Excessive agency
A read-only MCP reaches private repositories
The config shows a command and a token. It does not show the token scope or what the server does with it.
Supply chain
The assistant invents a dependency that happens to exist
The name sounds plausible. Someone registered it and the agent adds it to the lockfile as though it were established.
Test tampering
Tests pass because the agent weakened them
The build turns green after an assertion is removed, a case is skipped or a snapshot is refreshed without approval.
Sensitive information disclosure
A secret enters context without appearing in the diff
It can arrive through a pasted log, env output, an MCP reading .env or a value stored in the project file.
Full programme
What is taught, block by block
The sequence follows a real request: context enters, the agent gains capabilities, acts, and proposes a change that must clear controls.
How a development assistant actually works
Risk changes when model and orchestrator are separated.
- Model, orchestrator, tools and tool results.
- Tokens, context windows and what disappears between sessions.
- Static context versus dynamic context.
- Trust boundaries inside the IDE and repository.
Real case: Rules File Backdoor, Pillar Security, 2025.
Poisoned context and instruction chains
Text read by the agent can become policy.
- CLAUDE.md, Cursor rules and Copilot instructions as model-executed policy.
- Indirect prompt injection through repositories, issues and tool output.
- Invisible characters, hidden instructions and persistence between chats.
- Provenance for internal documentation, RAG and vector stores.
Real case: EchoLeak, CVE-2025-32711, and the path from external input to agent action.
Skills and MCP without blind perimeter growth
Installing behaviour and connecting a service are different decisions.
- When to use a Skill, MCP or a plain CLI.
- Tool poisoning in names and descriptions.
- Scopes, tokens, human identity and agent identity.
- Pinning, third-party review and removing capability after use.
Real case: GitHub MCP private-repo leak, Invariant Labs, 2025.
Autonomy, permissions and secrets
The same prompt carries a different risk at each autonomy level.
- Read-only, ask-first, auto-edit and full-auto.
- Allowlisting routine work and denying high-impact operations.
- Production credentials, shell, cloud tools and destructive changes.
- What may be pasted, what gets redacted and what must be rotated.
Real case: Replit against production and Nx s1ngularity driving local CLIs in yolo mode, 2025.
DevSecOps for code nobody will read in full
Authorship changes. Merge gates do not.
- A persistent Definition of Done in the project file.
- Unit, golden, smoke and end-to-end tests, and what each proves.
- SAST, secret scanning, dependencies and slopsquatting.
- Human review of assertions, CI, lockfiles, instructions and sensitive paths.
Real case: An Azure DevOps pipeline that blocks merge when evidence is missing.
Deliberate practice
Five labs. Five controls proven.
Every lab follows the same pattern: observe unsafe behaviour once, apply the control, and prove the outcome changed.
- 01
The project with bad instructions
Load a poisoned rules file, request product search, and find why the agent proposes vulnerable SQL.
Outcome: reviewed instructions, hidden characters found, and clean context in a new session. - 02
The Skill that should never be installed
Review a Skill that demands environment dumping and removal of human confirmation.
Outcome: a refusal justified by a specific line, not by a vague impression. - 03
Two MCP servers that look alike in config
Compare a scoped server with one able to read any file on the machine.
Outcome: only the allowlist is enabled and a request for secrets is blocked. - 04
Generated code against the harness
AI implements a function under a Definition of Done, then the team breaks it to prove the injection test fails.
Outcome: red-first evidence and explicit acceptance criteria for the pull request. - 05
The autonomy dial under pressure
A prompt tries to push the assistant into env, installs and test changes without approval.
Outcome: ask-first and the deny list proven in each participant's actual tool.
Material the company keeps
The workshop ends. The controls stay.
The material is built for reuse in the repository and in conversations between architecture, security and development.
- Definition of Done for AI changesA template ready to adapt to the project's instruction file.
- Workspace with five labsWriteups, safe and unsafe fixtures, and tests.
- One-page control cardContext, Skills, MCP, autonomy, secrets, code and supply chain.
- Starter deny listGit, shell, cloud and secret operations requiring a person.
- Context hygiene guideWhat to redact before pasting and what to do after disclosure.
- Autonomy matrixEquivalent modes in Cursor, Copilot, Claude Code and Gemini CLI.
- Multi-agent git disciplineExplicit paths, status before commit and file ownership.
- Reference pipelineAzure DevOps sample with real pytest and the next gates identified.
Who it is for
For organisations that have moved from trying AI to depending on it
A strong fit for
- Security architects turning AI risks into controls development teams can apply.
- AppSec, DevSecOps and Platform Engineering owners of pull-request gates and tool connections.
- Engineering managers and tech leads already seeing generated code in production repositories.
- Security champions and senior developers who will spread these practices through the team.
- Teams using Cursor, GitHub Copilot or Claude and still deciding permissions case by case.
Not the right workshop if
- The team has never used an assistant on a real repository.
- You need an introduction to LLMs or prompt writing.
- You need corporate policy, model governance or executive training.
- You expect a live audit or customisation on your own codebase.
Architecture of the day
Six hours covering the risk end to end
Explanation, decision and practice alternate throughout the day. There is no four-hour theory block followed by a rushed lab.
Map the system the team already uses
Model, orchestrator, context and tools. Trust boundaries come before controls.
Break trust in context
Poisoning, persistent instructions and lab 1. The team sees a repository rule alter generated code.
Decide what connects and with which permissions
Skills, MCP, identity, scopes, autonomy and secrets. Labs 2, 3 and 5.
Define what done means
Unit, golden, smoke, end-to-end, SAST, secrets and dependencies. The Definition of Done leaves the chat.
Block an unsafe change before merge
Lab 4, high-value human review and CI. Each participant selects one control to apply to a project.
Who teaches it
Security and development taught by someone who has worked on both sides
I am Daniel Alfocea. I have spent twenty years in development and security inside banks and large companies. At Banco Santander I was technical lead for the AI team while the area was being established.
I founded Navaja Negra and the OWASP Madrid chapter. I have presented research at RootedCON, RSA and Codemotion, and published more than one hundred open-source tools. With Alfonso Muñoz I wrote MCP Seguro, a practical guide to authentication, permissions and threats in Model Context Protocol.
This workshop joins two subjects usually taught apart: how an assistant works inside a repository, and how to build controls a development team can follow.
Format and investment
One team, one room and one shared system for decisions
The price covers preparation, six in-person hours and all working material. Twelve people is the limit because labs are reviewed while they happen; a larger room turns practice into a demonstration.
- Up to 12 participants from one team or collaborating functions.
- Delivered in English or Spanish.
- The company provides room, screen, wifi and laptops.
- Travel outside Madrid is agreed before the date is fixed.
Before booking