# Agent-first tool audit intake worksheet

Updated: 2026-05-15

Use this worksheet before asking for an AgentFirstTools audit or before running an internal review. It helps define the agent workflow, evidence sources, risk boundaries, and decision the audit should support.

Do **not** include secrets, customer data, production credentials, private keys, or regulated personal data. Replace sensitive values with examples or describe access patterns instead.

## 1. Decision to support

- Tool, product, API, CLI, MCP server, or workflow being evaluated:
- Decision needed:
  - [ ] Adopt / do not adopt
  - [ ] Compare against alternatives
  - [ ] Decide whether agents may use it unattended
  - [ ] Identify fixes before rollout
  - [ ] Other:
- Deadline or buying / implementation window:
- Who will use the result:

## 2. Agent workflow

Describe the exact workflow an AI agent should perform.

- Trigger: what starts the agent work?
- Inputs available to the agent:
- Actions the agent should take:
- Systems touched:
- Expected final state:
- Human approval points:
- What the agent must never do:

Example:

```text
When a support ticket mentions a broken integration, the agent should inspect logs,
search official docs, draft a fix PR, run tests, and leave a report. It must not
change production credentials, deploy without approval, or contact customers.
```

## 3. Evidence available

Share links or excerpts that are safe to review.

- Public documentation:
- API reference / OpenAPI / schema:
- CLI help output or command reference:
- MCP server manifest / tool list:
- Auth and permission model documentation:
- Sandbox account or recorded workflow trace:
- Logs, receipts, or audit events from previous runs:
- Error examples or known failure cases:
- Alternatives being considered:

## 4. Authority and safety boundaries

- Environments in scope:
  - [ ] Public docs only
  - [ ] Local sandbox
  - [ ] Test workspace
  - [ ] Read-only production evidence
  - [ ] Other:
- Actions explicitly out of scope:
- Data classes that must not be shared:
- Credentials available, if any, and their scope (describe, do not paste):
- Approval required before any mutation:
- Rollback or cancel mechanism, if known:

## 5. Agent-first readiness checks

Fill in what is known. Unknowns are useful audit findings.

| Area | Current evidence | Unknown / risk |
| --- | --- | --- |
| Discoverability | Help, docs, schemas, examples | |
| Scriptability | Non-interactive mode, JSON output, timeouts | |
| Scoped authority | Least-privilege tokens, roles, approvals | |
| Verification | Status endpoints, receipts, checksums, URLs | |
| Recovery | Idempotency, retry safety, rollback, resume | |
| Observability | Logs, request IDs, audit events, support bundles | |
| Human handoff | Escalation paths, review queues, approval gates | |

## 6. Commercial context

- Budget range, if known:
- Cost of choosing badly:
- Expected monthly / annual usage:
- Internal owner:
- Procurement, legal, or security constraints:
- Preferred output format:
  - [ ] Short recommendation memo
  - [ ] Detailed scorecard
  - [ ] Comparison table
  - [ ] Implementation safeguards
  - [ ] Vendor-facing fix list

## 7. Good audit question

A strong request is specific:

```text
Can our engineering agents safely use Tool X to triage failing CI jobs and open fix PRs
in a test repo, using only read-only CI logs and GitHub PR permissions, without humans
needing to interpret dashboards or hidden state?
```

A weak request is too broad:

```text
Is Tool X good for AI?
```

## 8. Send the inquiry

Use the audit inquiry form at:

https://agentfirsttools.com/services/agent-first-audit/#inquiry

Include a short summary, the workflow, the decision needed, safe evidence links, timing, and budget range if available.