✅ BenefitsAgileBeginner✨ AI-assisted

Benefits of a Security Champion on Every Agile Team

WittyTech Daily··4 min read
#security-champions#agile#threat-modeling#owasp

Your central security team has a ticket queue, and your sprint ends on Friday. A security champion on an agile team closes that gap: one engineer per squad who carries a security remit next to their normal work. OWASP's Developer Guide describes the champion as a member of the development team who acts as the liaison with the security team, and the role can sit with a developer, a tester or a product manager. Here is what that person gives a squad shipping AI features.

Four benefits of a security champion on an agile team

1. Threat modeling fits inside refinement. The Threat Modeling Manifesto reduces the practice to four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? The champion asks them on any story that adds a tool, a data source or a new model call, and writes the answers on the story. "Let the support agent look up orders" sounds harmless until someone notices that text pasted into an order note could tell the agent to issue a refund.

# Add to the Definition of Ready for stories that touch a model, a tool or customer data
threat_model_note:
  working_on: Support agent can look up an order by ID
  what_can_go_wrong:
    - Order notes contain text that tells the agent to issue a refund (indirect prompt injection)
    - The lookup tool returns another customer's order
  what_we_will_do:
    - Refund tool requires human approval
    - Lookup is scoped to the authenticated customer ID
  good_enough: Review in sprint review and add both attacks to the eval set

The note is short enough for a refinement session, and it exists before the first line of code does. Rename the keys to match your own story template.

2. Prompt-injection and dependency reviews happen before merge. The OWASP page for LLM01 prompt injection lists mitigations such as least privilege, human approval for high-risk actions and clearly labeling untrusted external content. It also says no foolproof prevention is known, so these measures reduce impact rather than remove the risk. The champion checks every pull request that touches prompts, tool definitions or dependencies against that list, and a code owners file makes sure they see those pull requests.

# .github/CODEOWNERS
/prompts/          @<your-org>/<squad>-champions
/agent/tools/      @<your-org>/<squad>-champions
requirements.txt   @<your-org>/<squad>-champions
package.json       @<your-org>/<squad>-champions

Change the paths to match your repository, then turn on "Require review from Code Owners" in branch protection, as described in GitHub's code owners docs. One approval from any listed owner satisfies the rule, so put at least two people in that team and a holiday won't block merges.

3. Answers arrive at standup speed. "Can the agent's API token live in the system prompt?" is a two-minute question for someone who knows the codebase, and a multi-day ticket for someone who doesn't. The answer is no, by the way: OWASP says to keep API tokens and privileged functions in application code, not with the model. The central team benefits too. OWASP's Security Culture guide suggests that one security staff member may support five champions, who each support their own team.

4. Security work shows up in the backlog with numbers. A champion turns findings into stories with acceptance criteria, so they compete for sprint capacity in the open instead of living in a spreadsheet nobody reads. The same guide suggests security OKRs, such as closing a percentage of critical and high vulnerabilities or completing a set number of threat models. After a few sprints you have a trend to show instead of an anecdote.

When a security champion is not worth it

The role fails in predictable ways:

  • No time budget. OWASP is plain that a champion "will dedicate time to security initiatives, such that they have less time to spend on development", and that management must agree to the commitment. Its example is 20% of their role. Without that, the title is a second job.
  • No authority. In my experience, a champion who cannot hold a pull request or escalate a risk to someone who can delay a release ends up as a note-taker.
  • Volunteered by default. OWASP says champions should be nominated, not assigned. A conscripted champion produces checkbox reviews.
  • Tiny teams. On a team of three with no AI features and no customer data, a shared checklist may be enough.

Start small. OWASP recommends a proof of concept with one or two champions before rolling the role out everywhere.

For a team putting agents in front of customer data, a champion is the cheapest way to make sure someone asks "what can go wrong" before production does.

← More in Agile