The request
{
"name": "wever_limit-substrate-check",
"arguments": {
"agent": "buyer-agent",
"limits": [
{
"name": "Per payment",
"kind": "per_payment",
"amount": "50 USDC",
"enforced_at": [
"system_prompt"
]
},
{
"name": "Daily",
"kind": "per_period",
"amount": "500 USDC",
"enforced_at": [
"gateway"
],
"counter": "agent_reported",
"agent_can_change": false,
"on_failure": "closed"
}
]
}
}What the report returns
Verdict: limits_are_suggestions.
| Finding, prompt only | Per payment rests on the system prompt, which buyer-agent can read and still exceed. |
|---|
| Finding, self reported counter | Daily is checked by a gateway against a total the agent reports, so the agent decides how much room is left. |
|---|
| Fix, Per payment | Move Per payment into code, a gateway, a platform control or a wallet policy that checks every action, and keep the prompt text as a description only. |
|---|
| Fix, Daily | Check Daily against a total the enforcing layer keeps itself, not one the agent reports. |
|---|
1 limit is a suggestion the agent can read and exceed: Per payment.
The agent runs under two limits. The per-payment cap lives only in its system prompt, so the agent reads it and can still pay past it. The daily cap sits in a gateway outside the agent's reach, and the gateway checks it against a running total the agent reports, so the agent still decides how much room is left. The report names both, so the owner moves the per-payment cap into the gateway and has the gateway keep its own total.