Keeping a Security Review Current as Agents Change

The change log is not the same as your git history. Git records what the code did. The change log records what changed about the agent's authority, and whether a human approved that change.

Keep it in the same repository as the agent configuration, or in a system your reviewers already check daily. Every entry should carry seven fields:

Populate the log automatically where you can. A CI job that diffs the prompt files, tool manifests and permission configuration on every merge, then opens a review task when the diff touches a protected path, removes the reliance on somebody remembering. Protected paths should include the system prompt directory, the tool registry, the memory schema and the credential scope definitions.

Two behaviors make the log useful rather than decorative. First, a change that is not logged blocks the deploy. Second, the log links to the artifacts: the test output, the reviewer sign-off and the deployed configuration hash. When an incident happens, the first question is always which version of the agent was running and what changed in it. A log with those links answers the question in minutes.

For teams that run several agent projects, a shared log with a consistent schema is worth the upfront cost. It becomes the source of truth for audits, for onboarding and for deciding which agents need a full review versus a quick one.

The recheck list should take under an hour for a small change and scale with reach. Five tests cover the highest-value ground.

1. Prompt injection. Re-run your injection suite against the new prompt or tool description, including indirect injection through retrieved content. Test direct override attempts, roleplay-based attacks and encoded payloads. Research cited by Fiddler AI on agent red teaming found roleplay-based prompt injection succeeded at 89.6% in their review, ahead of logic traps and encoding tricks, so roleplay cases deserve a permanent place in the suite (Fiddler AI). OWASP's cheat sheet lists the recurring patterns to build from: direct override, indirect injection, encoding, typoglycemia and HTML or Markdown injection (OWASP Prompt Injection Cheat Sheet).

2. Tool allowlist. Compare the tools the agent actually invoked in the last test run against its declared allowlist. Any tool invoked but not declared is a bug. Any tool declared but never exercised in six months is a candidate for removal. Okta's guidance on least privilege for agents notes that agents are often provisioned with broad access during development that is never reduced once the workload is stable (Okta). A recheck that only looks at the allowlist file will miss this drift; the invocation log is what tells you the truth.

3. Memory poisoning. Seed the test environment with a document containing an instruction, then check whether the agent writes anything derived from it into long-term memory and whether a later session acts on it. Also verify that memory writes are attributable and reviewable, and that a memory entry can be deleted without breaking the agent.

4. Credential scope. List every credential the agent can obtain at runtime and confirm each is scoped to the smallest set of operations the current task needs. Check that credentials are short-lived where the provider allows it and that no credential is shared between agents. Zenity's work on least agency makes the point that correct permissions can still permit inappropriate sequences of actions, so pair the scope check with a review of what the agent may do autonomously within that scope (Zenity).

5. Logging and alerting. Confirm that each tool call, each memory write and each credential use lands in a queryable log with the agent identity, the user on whose behalf it acted and the outcome. Then confirm the alerts you expect still fire: an unusual tool sequence, a burst of external calls, a memory write from an untrusted source. A change that quietly drops a log field is a material change.

Not every material change needs the full five tests plus two reviewers. Use reach as the multiplier.

The second reviewer for externally acting tools is the single highest-value rule in the table. A read-only tool that returns the wrong answer is a quality problem. A tool that can send email, move money, file a ticket or change a configuration is an authority problem, and authority problems deserve a second pair of eyes before deploy, not after.

A worked example: a support agent gains a refund_payment tool with a 500 unit cap. The diff is four lines of tool configuration. Under the table this is an externally acting tool, so the team runs the full checklist, updates the threat model to add a tampering path from retrieved customer email through the planner to the refund tool, and assigns a second reviewer from finance systems. Total recheck time: about two hours. The alternative, discovering after launch that an injected instruction in a customer email can trigger refunds, costs considerably more.

The process only holds if the pipeline enforces it. Three mechanics do most of the work.

First, a protected-path diff check in CI. Configure the build to fail when a change touches a protected path without a corresponding change log entry and reviewer sign-off. The check itself is small; the discipline it creates is large.

Second, a scheduled full review. Even with no changes, run the full checklist on a fixed cadence for agents with external reach. Model providers update hosted models without asking, and retrieved data changes as documents are added. Scheduled rechecks catch drift that no diff would reveal. Microsoft's AI red teaming guidance recommends ongoing, scheduled adversarial testing after deployment for exactly this reason (Microsoft Foundry).

Third, a version stamp at deploy time. Record the configuration hash of prompts, tools, memory schema and credential scope in the change log. When the alert fires, you can name the exact version under suspicion in a sentence.

# .agent-review.yml  (illustrative)
protected_paths:
  - prompts/**
  - tools/manifest.json
  - memory/schema.sql
  - config/permissions.yaml
required_reviewers:
  external_tool_change: 2
  default: 1
recheck_suite:
  - injection
  - tool_allowlist
  - memory_poisoning
  - credential_scope
  - logging

The exact syntax depends on your CI system, but the shape is portable: paths, required reviewers, test suite.

A one-time review produces a document. A repeatable process produces a trail: every change, who approved it, what was tested and what version shipped. That trail is what lets you answer three questions fast. Was the agent that just did something strange the reviewed version? What changed between the reviewed version and now? Who knew about the change and what did they check?

The recheck list also doubles as a template for the initial review. If you have not done a first review yet, the five tests and the change log schema are a reasonable starting point. Threat modeling methods for agentic systems can go much deeper, including scenario-driven attack trees that trace how malicious input moves from data through reasoning to tools to state (Christian Schneider), but a deep model that is run once and shelved is worth less than a shallow checklist that runs every time.

For teams that want external help setting up the cadence, scope thresholds and the first threat model, a short call can save weeks of internal debate: Quanta Consulting offers a free 30-minute discovery session that covers your agent goals and a tailored recommendation.

One more practical note: write the recheck list down in the repository as a checklist, not in a wiki. Checklists that live next to the code get used. Checklists that live in a tool nobody opens on a Friday afternoon do not.