This checklist is for a confirmed incident of AI tool abuse: an agent has already been shown to have used a tool or capability outside what it was actually meant to do, whether through manipulation, a crafted request, or an exploited gap in how its permissions were checked. It's written for whoever picks up the incident once that's confirmed, security on-call, an agent owner, or a platform engineer with access to the relevant kill switches. The sequence matters here more than usual, because a tool abuse incident often means an action is still executing or about to repeat, and stopping that has to come before any explanation of how the agent got talked into it. Work through containment first, then move to understanding exactly what happened and why the authorization layer didn't catch it.

Immediate containment

  1. Revoke or suspend the specific tool permission or capability that was abused, rather than pausing the entire agent if a narrower cut is available and fast enough.
  2. If the abusive action is still in progress or likely to repeat immediately, use the agent's kill switch rather than waiting to scope a narrower fix.
  3. Suspend credentials the agent was using for the abused tool if there's a chance they're still valid and reachable elsewhere.
  4. Confirm containment actually stopped the behavior by checking the tool's own logs or downstream system state, rather than assuming a permission change took effect instantly.

Impact assessment

  1. Use the audit trail to establish exactly which actions were executed, as opposed to attempted and blocked, since an unauthorized transfer that completed is a different incident than one an independent check caught.
  2. Identify every system, account, or party the executed action actually touched, not just the immediate output the agent returned.
  3. Determine whether the abuse happened in a single session or across multiple sessions or identities, since a repeatable exploit against the same gap changes the scope of the response.
  4. Establish a timeline for how long the tool was exploitable in this way, if that can be reconstructed from logs.

Authorization gap analysis

  1. Identify specifically why the authorization check didn't catch the request: was there no independent check at all, was the permission grant broader than the task needed, or did the check exist but rely on something the model itself controlled.
  2. Distinguish a missing check from a check that exists but was misconfigured, since the fix looks different depending on which one it was.
  3. Check whether the gap is specific to this tool or reflects a pattern used across other tools the same agent, or other agents, have access to.
  4. Confirm whether the abuse relied on a single crafted request or required sustained manipulation across a conversation, since that shapes whether a single-turn check is enough or whether the review needs to account for multi-turn context.

Remediation

  1. Narrow the tool's permission scope to what the task genuinely requires, rather than restoring the original broad grant once the immediate incident is handled.
  2. Add or strengthen an independent authorization check at the tool-call boundary, one that verifies the calling identity's actual permissions rather than trusting what the model claims it's allowed to do.
  3. For the specific action category involved, add human approval gating if the action's impact justifies it, particularly for anything irreversible or high value.
  4. Where the abuse exploited a permission shared across multiple agents or services, fix the shared grant rather than patching only the one agent where the incident happened to surface.

Verification

  1. Retest the exact abuse pattern, along with reasonable variants, against the fixed system before considering the incident closed.
  2. Check other agents with access to the same tool or a similarly broad grant for the same gap.
  3. Confirm the added approval gate or authorization check actually blocks the request in a live test, not just in the code that implements it.
  4. Document the specific gap and fix so it's available the next time a similar tool gets added or reviewed.

Where TELEON fits

TELEON's audit trail, applied through the gateway or supported middleware, gives responders the record of which actions actually executed versus which were attempted, which is exactly what impact assessment in this checklist depends on. Its runtime policy enforcement at the tool-call boundary is where the authorization gap identified during this response gets closed, whether that means a stricter permission scope, an independent check that doesn't rely on the model's own claims, or an added approval requirement for a specific action category.

Deciding which action categories deserve approval gating, and how narrow a given tool's permissions should be, are judgment calls the responding team and the tool's owner have to make. TELEON's enforcement layer is where that judgment gets implemented and applied consistently once it's made.

The checklist in short form

  1. Revoke the specific abused tool permission or capability.
  2. Use a kill switch if the abusive action is still ongoing.
  3. Confirm containment actually stopped the behavior.
  4. Use the audit trail to separate executed actions from blocked attempts.
  5. Identify why the authorization check missed the request.
  6. Narrow the tool's permission scope to what the task actually needs.
  7. Add or strengthen an independent authorization check, with approval gating if warranted.
  8. Retest the exact abuse pattern and check other agents for the same gap.

Tool abuse incidents tend to reveal a gap that was always there, a permission broader than it needed to be, or a check that trusted the model's own claim about what it was allowed to do. Stopping the immediate action matters most in the moment, but the incident isn't actually closed until that gap is identified precisely and narrowed or checked directly, and until the fix has been tested against the same pattern that got through the first time.