AI Agent Security Context Integration

This architecture guide is for teams that already have an AI coding agent and need a repeatable way to deliver recipes, repository rules, finding evidence, and review requirements into each run. If you are still selecting or setting up a tool, start with the AI coding agent comparison.

An agent should consume a recipe the same way a careful engineer would: read the relevant guidance, understand the repository rules, inspect only the needed evidence, make the smallest useful change, and stop when the work no longer fits the recipe.

The patterns below cover direct task links, vendored snapshots, native agent configuration, CI injection, and MCP-backed context. The per-agent setup pages show the exact files and commands for each tool.

Consumption patterns

The simplest path is to paste the recipe URL into the agent task:

Fix GHSA-xxxx-yyyy in this repository.
Use https://security-recipes.ai/security-remediation/vulnerable-dependencies/
as the remediation recipe.
Make one PR. Stop with a triage note if the fix needs a broad refactor.

Use this for one-off work, trials, and teams that do not want extra plumbing.

2. Vendored recipe snapshot

Copy the recipe or prompt into the repository as a versioned local file, such as:

SECURITY_RECIPES.md
.github/copilot-instructions.md
CLAUDE.md
AGENTS.md
.cursor/rules/security-remediation.mdc

Use this when the agent must work offline, when review requires pinned instructions, or when the recipe has been adapted for local build and test commands.

3. MCP knowledge connector

Expose the recipe index through an MCP server so the agent can search and retrieve guidance at run time. The optional server in this repository is read-only and suitable for that role. Rechecked August 23, 2026: MCP 2026-07-28 is still current and stateless. Development leftover CVE dumps stay noindex and are not catalog floors. Do not invent a fixed version when live GHAD is 404, vulnerabilities are empty, or NVD has no row.

Use this when a team wants agents to ask questions such as:

  • Which recipe matches this finding?
  • What prompt should I use for this tool?
  • What output contract should the PR body satisfy?
  • When should the agent stop and produce a triage note?

4. Native agent configuration

Most coding agents have a local instruction format. Put the recipe summary, guardrails, and output contract into the format your tool already reads:

Agent Primary place to put recipe rules
GitHub Copilot .github/copilot-instructions.md and issue templates
Claude CLAUDE.md, skills, and hooks
Cursor .cursor/rules/*.mdc
Codex AGENTS.md
Devin Knowledge entries and playbooks
Shiba Studio Per-agent instructions, skills, and MCP servers
Hermes Skills and agent-curated memory
OpenClaw Workspace AGENTS.md and workspace skills

Use native configuration for repeated remediation work. It keeps the task prompt short and makes the agent behavior more consistent.

5. CI or ticket injection

If findings already land in GitHub Issues, Jira, Linear, ServiceNow, SARIF, or another queue, have that system attach the matching recipe link and prompt block when it dispatches the agent.

Use this for security programs that want the same instructions applied every time a class of finding appears.

For GitHub repositories, the Security Health GitHub Action packages this pattern: it fetches recipe context from the hosted MCP server and runs toggleable, model-agnostic health checks as CI.

Add MCP context safely

MCP is useful because it lets agents read structured context instead of asking humans to paste screenshots or long scanner output into chat. Treat it as context first.

Good context sources include:

Start with read-only permissions. A connector that can create tickets, edit code, rotate secrets, deploy workloads, or change cloud configuration deserves its own security review.

Every recipe-backed agent run should carry this contract:

Scope:
- One finding per run.
- Use the named recipe and repository rules.
- Touch only files needed to remediate or prove the finding.

Context:
- Use MCP servers as read-only evidence unless the task explicitly grants write access.
- Cite the recipe, finding ID, and evidence sources in the output.

Stop conditions:
- Stop if ownership is unclear.
- Stop if the fix needs a schema, API, infrastructure, or broad architecture change.
- Stop if tests cannot be run or the result is ambiguous.

Output:
- PR with tests and residual risk, or a triage note explaining why no safe fix was made.

Guardrails that matter

  • Pin or vendor instructions for repeatable workflows.
  • Use branch protections, CODEOWNERS, required CI, and review gates for enforcement.
  • Keep MCP tokens scoped to the repository, organization, and data class the agent needs.
  • Log agent runs and MCP tool calls when the client supports it.
  • Never pass secrets, customer data, or private vulnerability details to a public model or public connector unless your policy explicitly allows it.

See also