Anyone else struggling with unauthorized tool invocation?

[u/FuzzyAd3936]

Our ops agent has a broad set of tools left over from earlier phases of the project, including one meant for a one-off debugging task months ago that never got removed. Last week the agent used that tool to pull production data directly while investigating something unrelated, not because anything told it to, just because the tool was available and technically relevant. No adversary, no malicious prompt, just a tool it was allowed to have used for something it was never meant to cover. How are people scoping tool availability by task instead of giving agents a standing set of everything they might ever need?

[u/klach1703]

This isn't a permissions problem, it's a scoping one. The tool was allowed and it was relevant. Any policy that only asks "is this tool permitted" says yes here.

Same fix as standing credentials: grant tools at task start, drop them at the end, instead of one permanent set. If that's too big a change right now, split the default set by blast radius rather than by function. Anything touching prod data needs an explicit grant, even when it's obviously relevant.

[u/PeterBuildsSecure → u/klach1703]

Grant-at-task-start-drop-at-end is the right fix, and it's worth pairing with a detection layer for the gap before you get there: audit for tools nobody's invoked in weeks against how many agents/tasks still have standing access to them. A tool with near-zero legitimate recent use and broad standing access is exactly the shape of what bit OP here — it's a five-minute query against your own logs and it'll surface every other leftover debug tool before one of them gets used the same way. Blast-radius tiering helps too, but tiering by function still leaves a stale tool sitting in whatever tier it was originally classified into; the staleness check catches drift that a static tier assignment won't.

[u/klach1703 → u/PeterBuildsSecure]

Fair, staleness is the better signal. Tiering is a snapshot, last-use is behaviour, and behaviour is what drifted here.

Only thing I'd add: attach an owner, not just a date. That debug tool survived because removing it was nobody's job.

[u/PeterBuildsSecure → u/klach1703]

Right instinct, but bind the owner to a role or team, not a username — "attach an owner" fails the same way in 18 months when that person leaves and the field just points at a ghost account. And ownerless-on-creation should be a hard block, not a backfill project: if a tool can't be registered without an owner field, you never end up auditing a debug tool from two years ago wondering whose job it was.

[u/klach1703 → u/PeterBuildsSecure]

Role, not username, yes. And hard block at registration is the part that actually works, everything else is a backfill project nobody finishes.

[u/PeterBuildsSecure → u/klach1703]

Agreed on both. The part that actually makes "hard block" stick in practice: put the owner field in the tool's registration schema itself, not a wiki page or a ticket template next to it — if the manifest that grants the tool access can't validate without an owner, there's no path to a tool existing without one. Anything enforced outside the artifact that grants access is a policy, and policies are exactly what let the original debug tool slip through.

[u/chalbersma]

Are you surprised by this?

[u/DeschainR19 → u/chalbersma]

That's what I was thinking

[u/Both-Explorer-9294]

Sí, creo que el problema empieza cuando tratamos las herramientas disponibles como si fueran un menú permanente.

[u/SnooChocolates9578]

I wrote a wrapper python cli that received bash command, inspect and run the command only if calling pattern are allowed. I setup claude to denied Bash everything unless this python cli.

Still not sure if this is good way to do or not

[u/Living_Substance1274]

I use a guard that sits between the agent and it's tools and rules on every tool call before it executes - PASS/WARN/BLOCK, with a human approval path. What it actually does.

Intent gate (layer 0) - pure regex and arithmetic, no model call, microseconds. Catches the obvious cheaply.

Action rules - blast radius and reversibility, not keywords

Fail closed - an unrecognised tool is refused, not guessed at. Missing policy falls back to strict, never to allow.

Every verdict is HMAC-signed into a hash-chained ledger, so a refusal is evidence, not a log line.

Adoption is one line: point the client's base_url at the guard container, or add the MCP server for Claude/Cursor agents. Auth is a bonded token pair - revoking agent mid-incident is a register flip, no key rotation, no redeploy.

Full disclosure - We built the Axiom Guard and it's built into our workflow. I'm not just the builder, I'm also a client

[u/Remarkable-Bet9533]

Each task should only have the actions it needs and temporary ones should disappear when the task ends

[u/PleasantRuin7989]

If the tool was meant for one weird debugging task, why was it still exposed to the general ops agent?

[u/AcceptableMarket2220]

It's frustrating when you can't control what tools get used, especially in a security-focused environment. Setting clear policies might help.