Reach Inventory: every connector your agents hold, with a job, an owner and a way out
by PaperChaseWebb
One row for every connector, MCP server, OAuth grant, API key and automation bridge your agents can use, each tied to a job and marked necessary, convenient or leftover. Scope granted is set against the scope the job needs, keys are named by where they live and never pasted, bridges list every app behind them, and leftover access is removed with a date and proof. Agents list and propose; removals, narrower scopes, rotations and new grants wait for your yes at your own terminal, tied to the sha256 of the inventory. Fifteen read-only checks run on the inventory.
- Price
- $19
- Difficulty
- Intermediate
- Setup
- 1 hr
- Format
- .md file
reach-inventory-every-connector-with-a-job-and-an-owner.md · 64 KB · instant download after checkout
Want this built for you instead? We can build it for you.
What you end up with
A file that answers "what can each agent touch, and why?", a one-page report of what to remove or narrow, and changes that happen only after your yes.
What you get
- 19 sections in one .md file
- The inventory folder: setup, agents and jobs, one row per piece of access, proposed changes, with blank templates
- Rules for need (necessary, convenient, leftover), scope granted against scope needed, bridges and the untrusted, private and outbound flags
- reach.py: an inventory hash, gate (exit codes 0, 11, 12), a one-page report, owner approval tied to a sha256, verify, and one use per yes
- reach_check.py: fifteen read-only checks, with a seeded test inventory (15 findings, then 0)
- A skill file for Claude Code, Codex and Hermes, an AGENTS.md snippet and a Grok Bot rules block
- Ten prompts, a failure table and a worked example
- A look at MCP inventory kits, connector checklists, OAuth app reviews and config scanners, with sources
Who it is for
Owners who want one checked list of what their agents can reach, and agencies that want a reach audit the client can read and keep.
Works with
Solid chips: the agent is named in this listing's own tools list. Dashed chip: A skill file for Claude Code, Codex and Hermes, an AGENTS.md snippet and a Grok Bot rules block; the scripts were tested on Linux with Python 3.13, the agent files were not loaded inside each harness.
Tools needed
Cost to run: The pack is the only purchase. The scripts use no model tokens; the agent that lists its access uses your own plan.
Time to result: A first checked inventory and report in an afternoon
How it works
Run the tests
Copy the reach-inventory folder and run sh test_all.sh.
Expected: 15 findings on the seeded inventory and 0 on the fixed one, 15 of 15 single faults caught alone, checker tests 29 passed, reach.py tests 29 passed, exit 2 on a missing folder.
List the agents and their access
Run reach.py init, list agents and jobs in agents.csv, then use prompts 1 to 5 to write one row per piece of access. Check each main account's connected apps page yourself.
Expected: reach.csv with a job, scope granted and needed, runs_as, credential_ref and last_used on every row, and no secret values anywhere.
Check and report
Run reach_check.py and fix the findings. Propose removals and narrowings in changes.csv with prompt 6, then run reach.py report.
Expected: Only R15 (ratification) left, and report.md listing write access, what to remove or narrow, removals with proof and changes waiting.
Ratify and approve
The owner runs reach.py approve DIR --inventory, then --changes for the ones they agree with, at their own terminal. Make each change in the app's settings, run done, then record the proof.
Expected: reach.py verify passes once per approved change, and an edit after the yes voids it.
Sample prompts, free to use
List everything you can reach from this session: connectors, MCP servers in your config, OAuth apps you were granted, API keys or tokens in your environment (names only, never values), and any automation bridge account. Say which file or settings page you read for each. Do not connect, test or change anything. For each row, name the job it serves from agents.csv. If you cannot point to a job, say so and mark need leftover. Do not invent a job to keep a row.
Prompts 1 and 3 of 10.
For every leftover row, every row decided narrow and every key made under a person's own login, check reach.py gate for the change kind. Where it says owner-yes, add a proposed row to changes.csv with a detail I can read in one line. Do not make any change.
Prompt 6 of 10.
Free preview of the file
# Reach Inventory: every connector your agents hold, with a job, an owner and a way out Version 1.0, 2026-10-29. By PaperChaseWebb. A stand-alone audit of what a business's agents can reach: connectors, MCP servers, OAuth grants, API keys and automation bridges, one row each, marked necessary, convenient or leftover. Four plain files, a script that gates what an agent may do about its own access and records the owner's yes, a read-only checker with fifteen checks, a one-page report, templates, a seeded test inventory, ten prompts and the tests, all Python 3 standard library. Works with Claude Code, Codex and Hermes through a skill file and an AGENTS.md snippet, and with Grok Bot through a rules block. Tested as described in section 11: everything ran on Linux with Python 3.13, including owner approvals typed at a pseudo-terminal. The skill file, snippet and rules block were not loaded inside the harnesses for this release, and the pack has not been run against a real business's connected accounts. Each is marked where it matters. Access piles up quietly. A connector gets added for one afternoon's job and stays. A key made under the owner's own login ends up in three agents. An automation bridge is connected once, and from then on one line in a config reaches every app that bridge can touch. Nobody remembers which grant does what, so nobody removes anything, and the list only grows. When something goes wrong, the first question is "what could that agent touch?", and most tea
Test record
- Date
- Oct 29, 2026
- What was run
- reach_check.py on a seeded inventory and a fixed copy, each planted fault alone, a missing input, and the unit tests. Linux, Python 3.13.
- Result
- 15 findings on the seeded inventory, 0 on the fixed one; 15 of 15 planted faults caught alone; exit 2 on missing input; nothing written. 29 checker and 29 reach.py tests passed, 0 failed.
- Not run
- The agent files inside Claude Code, Codex, Hermes or Grok Bot. A real business's accounts, connectors, MCP servers or bridges.
Copied from this item's dated test notes. What was not run stays in.
Worth knowing
- reach.py answers questions and records the owner's yes; it does not connect, revoke, rotate or grant anything, and it cannot stop an agent that never asks. This is not a sandbox.
- The skill file, AGENTS.md snippet and Grok Bot rules block were not loaded inside Claude Code, Codex, Hermes or Grok Bot for this release, so how completely each harness lists its own access was not measured. The pack was not run against a real business's accounts, and no connector, MCP server or bridge was exercised. Grants made outside an agent's config need a human look at each app's connected apps page. The secret check matches common key shapes and long unbroken strings; it can miss a short password. The checker tests the structure of the inventory, not whether a scope name is right for a given app. The test business is made up. Linux only; Windows was not tested.
- Not an MCP code scanner, not an identity governance platform and not a compliance certification.
- The approval step refuses piped input and the environment variables Claude Code, Codex, Hermes and Grok Bot set. That stops an agent approving by mistake; it is not a lock against someone with the same account.
- On 2026-10-29, on Linux with Python 3.13: reach_check.py gave 15 findings on the seeded inventory (each check once) and 0 on the fixed one, caught 15 of 15 single faults with only its own check, wrote nothing, and exited 2 on a missing folder, any of the four required files missing, or broken reach.json; checker tests 29 passed, 0 failed; reach.py tests at a pseudo-terminal 29 passed, 0 failed.
Questions
How is this different from a security checklist?
A checklist is ticked once per connector. Here every piece of access is a row tied to an agent, a job and an owner, with scope granted against scope needed, last used and expiry dates, removal proof, and a checker that runs on the file.
Can the agent remove or add access by itself?
No. Listing and proposing are the agent's; remove, narrow, rotate, add and widen are owner-yes, approved by the inventory sha256 at your own terminal, and verify passes once. Sharing a credential and granting admin are never proposed.
Do I paste my API keys into it?
Never. credential_ref names where the key lives, such as a vault entry. The checker flags common key shapes and long unbroken strings in every inventory file.
I own the Agency Install Kit. Do I need this?
The Install Kit's binder has a six-column reach.csv with one check. This pack grows it into a full audit with fifteen checks, changes and a report, and prompt 10 converts the binder's file.
Details
Version 1.0 · Updated Oct 29, 2026 · Markdown version of this page
License: Use on your own business and to audit access for your clients. Do not resell or republish the pack itself. Download terms
Related
Reach Inventory: five rules and a five-check script (free sample)
From the Reach Inventory: five rules for the connectors your agents hold (a human owner, a job for every connector, leftover means removed, write access has an approver, unused access gets reviewed), and a read-only script that checks one reach list for them.
Agency Install Kit: install one agent workflow in two weeks, with a binder a script can check
Five paid packs and the free Readiness Self-Check, tied into one two-week install by a new Install Binder: plain files for readiness, one workflow, agent owners and tested pauses, a gate register, a reach inventory, a cost cap, a dry run with refusal cases, a scorecard with kill rules and a run sheet with an off switch. A fifteen-check script names every missing decision, and the owner's go-live yes is tied to the binder's sha256.
MCP server setup playbook: connect your agent to real tools without handing over the keys
Pick the fewest MCP servers for a job, check them before installing, scope the credentials, configure five clients, test with MCP Inspector and build a small read-only server of your own.
Vet Before You Install: twelve checks, a sandbox recipe and a tested vetting folder for third-party agent code
Decide whether a skill, plugin, mod, MCP server, connector, repo or model gets into your agent setup: sort the seat, read every file that runs, map reach and the data path, pin and vendor it, trial it in a sandbox with a planted fake key, then record a decision the owner approves at their own terminal. v1.1 adds a seat sort before any vetting, two new checks (data path and reach, approval surfaces), evidence tiers, twelve token classes including hidden text, encoded strings, startup file edits and approval hooks, a fresh-session second read, data path questions for proxies and routers, dependency and model weight pinning, a fifth decision (not vettable) with recheck dates and an approved shelf, more special cases, a vetting folder with a fifteen-check read-only checker and an owner approval helper, agent files for Grok Bot, Claude Code, Codex and Hermes, and twelve new prompts (27 in all). Price unchanged.
Desk Authority Map: who in your agent fleet may decide what
Four plain files say, for every desk and action, decide, propose, ask-owner or never, with dollar limits, escalation and the evidence each desk owes. Agents ask authority.py before they act and get the answer as an exit code; anything not in the map is never. Owner yeses are typed at the owner's terminal, tied to one request's sha256, good for one use, and refused inside an agent. Fifteen read-only checks run on the map itself.
Shrink the Attack Surface: patch with proof, then attack your own agent's tools
Your agent lists everything your app exposes, read-only: routes, open ports, public buckets, secrets in the repo, unused dependencies, debug endpoints, admin paths, CORS, API key scopes and its own tool permissions. You decide keep, remove or lock for each. Every fix gets a proof that fails before the change and passes after it, and the proof stays as a regression test. Then attack drills run against your agent's own tool gate, offline: pressure, impersonation, injected tool output, stale and non-owner approvals and a failing tool. Each is judged by what the tools actually did, and every drill that gets through becomes a test that fails before the fix and passes after. A failing tool stops at a retry budget and asks you, and every approval is yours, typed at your own terminal and tied to a sha256.
Production Readiness Audit: decide from evidence whether an agent system can go live
Twelve areas, each pass, gap or na, and every pass points to a dated evidence file. Gaps get a named owner and a due date, five areas block go-live until fixed, drills are run rather than described, and the verdict is signed by someone who did not build the system. A fifteen-check script reads the folder, the report is sealed to a hash of the evidence, and the owner's go-live yes is tied to the report's sha256.
Executive Morning Brief: a daily brief for owners where every line has a source
A morning brief your agent builds from your own calendar, inbox, payments and tasks, read-only, with every line citing a record you can open and every figure copied from it. Sources that failed are named instead of hidden, a quiet day says so, and replies or calendar changes stay drafts until you say yes at your own terminal, tied to the sha256 of that day's brief. Payments and deletions are never drafted. Fifteen read-only checks run on the brief before it renders.
Agent Readiness Self-Check: score one workflow before you hand it to an AI agent
A free self-check for agencies and small businesses. Name the decision, then score one workflow across eight areas (workflow mapped, data access, approval gates, owner per agent, handoffs, cost tracking, security and vetting, measurement) with an evidence rule, three gate rules and a skeptical pass, and read your band and the next steps it allows. v1.1 starts with the decision the score will change, scores unknowns as unknown, adds rules for conflicting facts and lookalike public records, ties every band to the next steps it allows with the Production Readiness Audit before go-live, makes owner approval concrete (prepared and approved status, a one-reply approval line, decisions the agent must leave open, a done test), adds agent files for Grok Bot, Claude Code, Codex and Hermes, a second worked example (missed call to booked job), a readiness folder with a fifteen-check read-only checker, a front door test with four questions to ask anyone selling you an agent install, and a plain note on how it was tested. Still free.