Was reviewing the NEAR IronClaw agent execution flow docs. The standard pattern is the enclave calls `nairc::execute` on the NEAR side, which spins up the agent. Turns out you can—and should—constrain the gas for that single agent transaction.
Found it buried in the `AgentExecutionConfig`. If you don't set it, it defaults to the attached gas for the whole `execute` call, which is asking for trouble.
```rust
let config = AgentExecutionConfig {
gas: Some(30_000_000_000_000), // 30 TGas, for example
..Default::default()
};
```
Why this matters:
* An agent with a bug or a maliciously crafted prompt could burn your entire gas allowance on nonsense.
* Prevents a single agent from consuming resources meant for a batch of sequential actions.
* It's a logic bug if your app assumes per-agent gas limits but doesn't enforce them.
Without this, you're basically giving any agent execution unlimited draw from your gas wallet. Easy oversight, expensive consequence.
-- x
disclose responsibly
Good catch. That default is a trap. If you're handling multiple agents in one execute call, not setting this means the first one eats everything and the rest fail.
Also, don't just set the limit and forget. You need to monitor for GasLimitExceeded outcomes. The agent's result will be null, and you'll still be charged up to the limit you set. Handle it in your callback or you'll have dangling states.
>monitor for GasLimitExceeded outcomes
Yes, and this is where a clear agent state machine helps. If the result is null from a gas limit, your callback should explicitly transition that agent to a failure or retry state, not just log it. A dangling 'processing' state can break your reconciliation logic later.
I usually add a dedicated handler branch for this in the callback, separate from other execution errors. It's a distinct failure mode.
trivy image --severity HIGH,CRITICAL
Yep. Found this the hard way last week.
Test agent got stuck in a loop due to a bad prompt. Ate 50 TGas of a 75 TGas batch call, blew the whole operation. Cost real money.
Your config example is correct, but put that 30_000_000_000_000 in a const. You'll reuse it everywhere and it's too easy to fat-finger.
disclose responsibly
>put that 30_000_000_000_000 in a const
Agreed, but I'd take it a step further and make it an environment variable. A const in your code is still baked in.
If this is meant to be a flexible limit for different agents or environments (testnet vs mainnet, cheap vs expensive agents), you're going to be recompiling for every adjustment. Much easier to source it from config and fail fast if it's missing.
Also, please tell me that magic number isn't sitting directly in your git history. Someone's going to cargo-cult it without thinking.
mj
Oh please. You're acting like this default is some hidden landmine, but anyone who actually reads the IronClaw flow should see the risk from a mile away. The docs are pretty clear about the sequential execution model.
The real problem isn't the default. It's this cargo-culting of setting a single magic number as a "safety" limit. 30 TGas? For what agent? Doing what? The whole premise of agents is that they have wildly different compute and storage patterns. Setting a blanket limit just means your expensive, legitimate agent will constantly hit the wall while your trivial ones burn pennies. You've traded one blind spot for another.
Now you've just moved the logic bug from "no limit" to "arbitrary, poorly-calibrated limit." Have you actually profiled your agents' gas usage under realistic loads to pick that number? Or is it just the first big round number you saw in a forum post?
- P