Parameter manipulation in AI tool calls happens when the model calls the correct tool but with arguments that have been altered, either through prompt injection, misleading context, or a plain reasoning error, so the actual effect of the call diverges from what the legitimate request intended. This is a distinct risk from calling the wrong tool entirely, and it's arguably more dangerous, because a call that looks entirely appropriate from the outside, the right tool, a plausible-looking parameter, can still do something the original user never asked for. A refund tool called with a manipulated amount, or a messaging tool called with a manipulated recipient, both look like normal tool usage right up until someone checks the actual numbers.
Constrain parameters to the narrowest shape the task allows
A parameter defined as an open string invites more risk than one defined as an enum of specific allowed values, a bounded numeric range, or a reference that must match an existing, authorized record. Wherever the underlying task allows it, narrow the schema so an out-of-bounds or manipulated value simply fails validation rather than reaching the underlying system.
Cross-check parameters against the session's actual context
A tool call's parameters should be consistent with what's actually happening in the conversation and the user's own data. A refund amount that doesn't match any recent transaction, or a record identifier that doesn't belong to the requesting user, is a mismatch worth catching through a cross-check against real data, not just a format check against the parameter's shape.
Apply business-rule limits independent of the model's reasoning
A spending limit, a maximum transaction size, an approved list of recipients, these need to be enforced as hard limits outside the model's own judgment, since a manipulated model can be talked into ignoring a soft instruction but can't argue its way past a limit enforced at the tool or gateway level.
Watch for parameters that drift from a user's established pattern
A user who has never sent more than a modest amount suddenly generating a call for a much larger one, or a session suddenly requesting access to records far outside its typical pattern, is a signal worth flagging even when the parameter itself passes every static validation check. Behavioral context catches manipulation that a purely static rule set will miss.
Re-validate parameters at the point of execution, not just at generation
A parameter that was valid when the model first generated it can become invalid by the time it's actually executed, if intervening steps changed the relevant context. Validate immediately before execution, not just once earlier in the pipeline, so a race condition or a multi-step chain doesn't let a stale or manipulated value slip through.
Build parameter manipulation testing into your release process
Treat adversarial parameter testing as a standard part of releasing or updating a tool, not a one-time exercise done during an initial security review and never repeated. Write test cases that specifically try to push amounts past limits, reference records that don't belong to the test user, or embed injected instructions inside otherwise valid-looking string fields. Run these tests every time the tool's schema changes, since a new parameter or a loosened constraint can quietly reopen a gap that an earlier round of testing had already closed.
Don't let convenience defaults become a manipulation path
A tool that fills in a missing parameter with a convenient default, the most recent record, the currently logged-in user's own account, the last-used address, can be exploited if an attacker can influence which value ends up being "most recent" or "currently active" through an earlier step in the same session. Review default-filling logic with the same scrutiny you'd apply to an explicitly supplied parameter, since a default isn't automatically safe just because no one typed it directly.
Where TELEON fits
TELEON enforces policy at the tool-call boundary, checking parameters against defined rules and the requesting identity's actual permissions at the point a call is about to execute, which gives teams a consistent place to catch manipulated parameters regardless of which tool or MCP server is involved.
Defining the specific business rules, spending limits, and behavioral baselines that make sense for a given tool is domain-specific work that depends on what normal, legitimate usage actually looks like for that particular system.
A short checklist
- Constrain tool parameters to the narrowest schema the underlying task allows.
- Cross-check parameters against the user's actual, existing data before executing.
- Enforce spending, volume, and recipient limits as hard rules outside the model's reasoning.
- Flag parameters that drift significantly from a user's established pattern.
- Re-validate parameters immediately before execution, not only at generation time.
- Log both the generated parameters and any adjustments or rejections applied.
- Test deliberately with manipulated parameters embedded in adversarial prompts.
Parameter manipulation is easy to underestimate precisely because the tool call itself looks completely unremarkable. The fix isn't more suspicion of the model in general, it's treating every parameter as something to verify against real, independent facts before it's trusted to drive an actual action.