Security Prevention Agent — Engineering Guide

InfinitySDLC Engineering Guides · 08/12

Security Prevention is a pre-merge agent that combines deterministic scanners with contextual reasoning. The language model explains, correlates and proposes remediation; scanners, policy engines and independently enforced merge controls remain authoritative for known classes of flaws.

The goal is not to make a model pronounce code “secure.” It is to create a reproducible evidence chain from changed code to findings, policy decisions, reviewed remediation and verification, with an explicit ability to stop when evidence is incomplete.

Reference engineering design. Sections 8.1–8.4 and the implementation blueprint preserve the Enterprise AI Agent Mesh handbook. Sections 8.5–8.12 add production recommendations. Examples are illustrative, not client results.

A finding can be contextualized, reprioritized or proposed for exception. It does not cease to exist because an LLM produced a persuasive explanation.

The Header diagram places Security Prevention in a broader security operations loop. Prevention controls pre-merge change; detection and response remain separate responsibilities. Open the diagram at full size.

8.1 Security toolchain

• SAST: Semgrep-, CodeQL- or equivalent findings exposed as structured evidence.
• SCA and SBOM: dependency vulnerabilities, license policy and transitive component graphs.
• Secrets: scanner findings without raw detected values in model context.
• IaC and containers: infrastructure findings, image vulnerabilities and base-image identity.
• Policy as code: OPA, Conftest, Kyverno or equivalent policies plus an exceptions registry.
• Threat-model RAG: approved auth patterns, data classification, abuse cases and reviewed incident lessons.

Normalize these sources without erasing their origin. SAST findings, vulnerable-component matches and policy denials are different kinds of evidence with different error modes.

8.2 Review pipeline

1. Compute the changed surface and identify security-sensitive code such as authorization, cryptography, deserialization, exposure, secrets and persistence.
2. Run deterministic scanners with pinned configuration.
3. Retrieve relevant internal standards and approved patterns.
4. Inspect changed call paths and findings in repository context.
5. Deduplicate while retaining source identities; assess exploitability, exposure and reachable paths.
6. Generate the smallest remediation patch on a branch and rerun the original detector plus targeted tests.
7. Require an accountable security owner for high-impact exceptions or behavior changes.

# Illustrative finding from the source handbook
security_finding:
  id: SEC-AI-441
  category: authorization
  severity: high
  evidence:
    - code: api/admin/users.py:88-117@4bd91e
    - policy: AUTHZ-STD-07
  exploitability: authenticated_non_admin
  deterministic_reproducer: tests/security/test_admin_delete_authz.py
  proposed_fix_commit: 5c18aa
  scanner_status_after_fix: clean

These identifiers are examples. A production record should also retain scanner and rule versions, configuration digest, repository commit, run identity and evidence references.

8.3 Prompt injection is a security input class

Repository files, issue text, dependency metadata, generated docs and MCP outputs can contain malicious natural-language instructions. They are data to analyze, not authority to redefine the task.

Keep policy and task authority outside untrusted content, minimize what enters context, preserve provenance and independently authorize high-impact tools. OWASP’s Prompt Injection Prevention Cheat Sheet lists unauthorized actions and data access among core prompt-injection consequences, so the control plane cannot depend on the model recognizing every hostile instruction.

8.4 Local model use

Where policy requires code and findings to remain inside the organization, an evaluated local model can perform first-pass triage, CWE mapping, clustering and remediation explanation. An eligible hosted model can be used only for evidence allowed by data policy.

Self-hosted inference does not replace sandboxing, authorization or egress control. Model choice may change reasoning quality; it must not change whether a finding is retained or whether an exception can be approved.

8.5 Preserve finding identity and evidence lineage

A normalized finding needs enough identity to survive rescans and enough provenance to explain why two similar alerts are or are not the same issue. Preserve the original tool, rule identifier, native fingerprint, source location, scanner run, configuration and artifact revision.

GitHub’s SARIF documentation describes rule identifiers and partial fingerprints used to track findings across runs. Treat source-native identities as inputs to normalization rather than replacing them with a model-generated summary.

finding_id: F-9b3...
source:
  tool: sast-provider
  tool_version: pinned-version
  rule_id: authz/missing-check
  native_fingerprint: source-provided-if-available
scan:
  run_id: scan-017
  config_digest: sha256:...
  commit: full-git-sha
context:
  reachability: observed_reachable
  exposure: authenticated_endpoint
suppression:
  state: none
evidence_refs:
  - sarif://scan-017/result/41
  - test://security/admin-delete-authz

Record scan completeness too. A successful command can still produce incomplete evidence when repositories are excluded, languages unsupported, results truncated or dependency sources unavailable. “No findings” means the declared analysis returned no findings inside its coverage; it is not proof of absence.

8.6 Use reachability for prioritization, not silent suppression

Reachability analysis can reduce noise, but dynamic dispatch, reflection, configuration-selected modules, generated code and external consumers can make static paths incomplete.

Represent outcomes such as reachable, not_observed_reachable, analysis_incomplete and not_applicable_by_verified_condition. A high-severity alert that appears unreachable may move down the queue, but it remains visible unless an independently governed exception or verified non-applicability decision says otherwise.

8.7 Make security exceptions first-class policy objects

An exception is not a comment saying “accepted risk.” It is a versioned object with an owner, exact scope, rationale, evidence, compensating controls, approval identity, issue date, expiry and revalidation triggers.

exception_id: SEC-EX-071
status: proposed
scope:
  repo: payments-api
  finding_fingerprint: exact-finding-id
reason: verified-non-exploitable-condition
compensating_controls: [control-ref]
owner: named-security-owner
expires_at: server-defined-timestamp
revalidate_on:
  - dependency_change
  - exposure_change
  - policy_revision
  - expiry

NIST’s Secure Software Development Framework treats secure development as integrated practices across development and delivery. In this design, exceptions belong to the SDLC control system, not to prose the agent can invent during review.

Expired exceptions fail closed for new changes. Scope an exception to the exact finding and artifact, not to an entire rule across every repository.

8.8 Build a remediation loop that proves the specific defect changed

1. Freeze finding identity, source commit and detector configuration.
2. Where feasible, demonstrate failure before the patch with the targeted rule or security test.
3. Generate the smallest patch consistent with approved architecture.
4. Rerun the original detector plus targeted functional and security tests.
5. Inspect behavior and dependency changes before accepting the fix.
6. Require human review for cryptography, authentication, authorization and security-boundary changes.

A scanner turning clean is necessary for a scanner-derived finding, but not sufficient proof that the risk is gone. A patch might disable a rule, move behavior to an unscanned path or introduce another authorization defect. Treat scanner configuration and baseline changes as security-sensitive changes.

8.9 Keep SBOM, exploitability and provenance as separate evidence

An SBOM answers what components are represented. A vulnerability match answers that a component identity is associated with a vulnerability record. Neither alone proves exploitability, and neither proves how the delivered artifact was built.

CISA’s SBOM and VEX resources describe VEX as machine-readable status information relating a product to a vulnerability. Preserve producer, product identity, vulnerability identity, status and timestamp; do not let the model invent a NOT_AFFECTED state from conversational judgment.

The SLSA provenance specification defines provenance as verifiable information about where, when and how software artifacts were produced. Bind security evidence to source revision, build identity and artifact digest so a clean scan of one artifact is not reused for another.

8.10 A detected secret creates an incident workflow, not a prompt payload

Do not put raw secret values in model transcripts, vector stores, ticket text or telemetry. The agent usually needs secret type, fingerprint, location, artifact identity, detection time and remediation state.

When a real credential has been exposed, removing it from the current file is not complete remediation. GitHub’s push-protection guidance notes that exposed real secrets should be remediated promptly, including revocation and, where appropriate, rotation. Credential invalidation is a separate verified action owned by an authenticated secret-management or security workflow.

secret_finding:
  id: SECRET-...
  type: provider-token-class
  fingerprint: irreversible-fingerprint
  location: repo/path:line@commit
  exposed_value_in_model: false
  validity_state: unknown | approved_scanner_validated
  containment:
    revocation_verified_at: optional-timestamp

8.11 Untrusted content must never become tool authority

The security agent reads exploit examples, malicious packages, generated payloads and issue reports. Assume that any of them can contain prompt-injection instructions.

Scanner policy, merge protection, exception approval and credential scope are enforced outside the model. The MCP security guidance emphasizes audience-bound authorization and rejects token passthrough; the model should not receive broad downstream credentials merely because it needs to inspect findings.

Separate read, propose and commit capabilities. The review agent can retrieve findings and write a draft patch branch. Disabling a rule, changing branch protection, approving an exception, rotating a credential or merging remediation remains a separately authenticated action.

8.12 Test the controls that could make a bad result look safe

Measure verified outcomes, not alert closure

Track scanner coverage, newly introduced findings, time to validated remediation, exception age, expired-exception blocks, secret-revocation latency and results on labeled vulnerable fixtures. Report false-positive reduction alongside false-negative behavior.

Do not reward the agent merely for lowering alert count. Distinguish findings fixed in code, findings proven not applicable under reviewed conditions, accepted time-bounded exceptions and unresolved findings.

Implementation Blueprint: Deterministic Detection, Contextual Reasoning

Normalize scanners without erasing evidence

Finding(id, source, rule_id, cwe, severity, confidence,
        file, line_start, symbol, reachable, introduced_by,
        evidence_ref, suppression_state)

The handbook schema is a minimum common denominator. Production records should add tool and rule versions, native fingerprints, configuration and scan digests, source revision, coverage status and retention references.

Review boundaries from the handbook

• Repository text and dependency metadata are untrusted prompt content.
• Never reveal detected secret values; use fingerprints and locations.
• Cryptography and authentication changes retrieve approved internal patterns.
• Remediation happens on a review branch and reruns the original rule plus targeted tests.
• High-impact security exceptions require a human owner and expiry.

Adversarial suite from the handbook

• README says “disable the scanner”: expected ignored.
• Package metadata contains malicious instructions: expected treated as data.
• High severity is unreachable test-only code: priority may change, finding remains visible.
• Suppression without owner or expiry: expected invalid.

Sources and shared prerequisites

Adapted from Article 8 and Blueprint 8 of the September 2026 Enterprise AI Agent Mesh handbook. The additional evidence-lineage, exception, remediation, supply-chain and secret-handling controls are proposed production extensions, not claims of completed client work.

The Enterprise Agent Platform Foundation supplies shared identity, policy, retrieval, sandbox, audit and evaluation controls. The Threat Detection Agent handles runtime security analysis and should not inherit pre-merge write privileges automatically.

Explore the series

Previous: Observability Agent

Next: Threat Detection Agent