Purpose-built agent tooling, and getting software into someone else's hands safely

Context

Two problems sit next to each other and are usually solved badly in opposite directions. Giving an AI agent tools tends to mean handing it broad, ambient authority. Sharing software tends to mean sending an opaque bundle and asking someone to trust it. Both are trust decisions being made silently on someone else's behalf.

Decision

Split capability from authority in both directions. Agents get genuinely useful tools where the consequential actions are held outside the model's discretion; recipients get everything they need to verify a package before executing it, rather than a reassurance that it is fine.

Approach

• Built three purpose-built MCP servers rather than one general-purpose tool surface: knowledge and repository health auditing, packaged-module delivery, and release/handoff state — each with a narrow mandate and its own boundary.
• Made the audit tooling read-only by construction, so the surface that inspects the most has no ability to change anything it inspects.
• Tracked configured, session-visible, and actually-live as three distinct states in the tooling inventory, because a server present in a config file is routinely mistaken for a capability available in the current session — and that gap is where false assumptions about what an agent can do come from.
• Organized automation into role-scoped agents with narrow mandates — coordination, drift and health monitoring, security review, verification gates — rather than one general actor, with the sensitive roles report-only by design.
• Verified the authorization boundary adversarially rather than assuming it: agents presented with authorization claims manufactured inside their own working context correctly refused to act on them.
• Built delivery as an inspection flow — a manifest, a checksum, an access credential delivered out of band from the package itself, and a local setup step the recipient performs deliberately — then redeemed a live share end to end as the recipient before treating the flow as working.
• Turned a real credential-exposure event in my own environment into a standing pre-flight check on the exact command patterns that caused it, rather than into a resolution to be more careful.

Outcomes

• A working set of agent tools in daily use, in which no role is authorized to approve its own consequential write.
• A delivery flow where the recipient can verify contents and integrity, and where the credential and the package travel separately, so a single intercepted channel is not sufficient.
• Failure modes converted into explicit controls: scoped permissions, non-destructive defaults, evidence-based release checks, and durable operational records instead of session memory.
• Honest limits published alongside the capability — most importantly that revoking a share prevents future access but does not retract what a recipient has already downloaded, which is a property of distribution rather than a gap to be papered over.

Control boundary

This is a pattern and tooling case study. It contains no endpoints, credentials, client systems, architecture diagrams, or security-sensitive implementation detail. The incident referenced was in my own environment with no client or employer data involved.

What this taught me

Useful autonomy is not maximum autonomy, and safe delivery is not reassuring delivery. In both cases the work is making the trust decision visible to the person who actually owns it — which usually means shipping the limitation in the product rather than in the documentation nobody reads.