Review unexpected agent mutations

Inspect high-impact audit actions in a human-controlled owner session, separate completed changes from uncertain attempts, and prepare an incident handoff.

Updated · published

markdown for agents →

difficulty advanced · time to value 10 minutes · execution human review required

Start from this

Review the last 24 hours of audit history for high-impact actions such as flag deletion, broad suppression, cohort deletion, publication changes, webhook changes, and automation policy changes. Return evidence and recommended owner decisions; do not send messages or mutate anything.

Why this is a human review

Project-wide audit history requires owner authority. An automation runner is bound to one automation and cannot receive an owner key, perform generic audit reads, change flags or policies, publish data, or contact an external channel. Installing AGENTRY_PRIVATE_API_KEY in a scheduler would erase that boundary.

This workflow therefore reviews a bounded window interactively. It produces an evidence-backed handoff; a human decides whether to revoke a credential, restore configuration, open an incident, or share the findings.

Run the review

Fetch the filtered OpenAPI schema before making each call, then read:

GET /v1/audit/recent?hours=24
GET /v1/projects/:project_id/automation-control

Start with completed audit operations. Inspect attempt rows only when an external-provider action may be intent, failed, or indeterminate. indeterminate means provider state is unknown; it is not permission to retry.

Prioritize:

  1. Credential creation, revocation, expiry, or unexpected actor changes.
  2. Feature-flag, suppression, cohort, survey, publication, or webhook changes.
  3. Global or per-automation kill-switch and policy changes.
  4. Approval decisions and cancelled runs with unresolved external follow-up.
  5. Bursts of similar mutations outside the expected change window.

For each item, preserve the audit ID, actor, action, resource, committed time, and exact evidence status. Do not infer success from a runner-authored summary.

Output format

Audit review — <UTC window>

Needs an owner decision
- <audit/run id> — <action> — <why it is unexpected> — <safe next check>

External state unknown
- <attempt id> — <provider object> — <authenticated provider check required>

Expected completed changes
- <audit id> — <action> — <actor> — <committed_at>

Readiness gaps
- <fact the available audit/control data cannot establish>

Keep raw secrets, webhook URLs, customer data, and copied provider payloads out of the report. If the reviewed result should go to security or oncall, let the human choose the audience and destination after reading it.

Recurring detection boundary

There is no versioned audit-monitoring automation template today. Do not give a runner generic audit access or reproduce this owner read in a scheduler. If immediate detection is a requirement, treat a narrowly scoped, immutable server-owned source and explicit delivery policy as missing product capability rather than improvising broader authority.

Variations

  • “Review only credential and membership changes in the last seven days.”
  • “Compare completed actions with the approved maintenance-window checklist.”
  • “Reconcile cancelled runs whose external provider state is still unknown.”
  • “Draft a credential-rotation or incident checklist from these findings, but do not execute it.”

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.