WHEN gas_used > 800000
THEN complexity_score <= 50 // throttle expensive ops
It's closer to metered execution than sandboxing, but fits the same formal verification approach. VARIABLES {
action: {"TRANSFER", "WITHDRAW", "DEPOSIT"}
amount: 0..100000
country: {"TR", "US", "EU", "NK"}
is_vip: {"TRUE", "FALSE"}
kyc_level: 0..5
risk_score: 0..1
device_trust: 0..1
}
// Hard boundary: never flexible
STATE_CONSTRAINT no_sanctioned_country {
WHEN country == country
THEN country MUST NOT BE "NK"
}
// Soft boundaries: context-dependent
STATE_CONSTRAINT transfer_limit_non_vip {
WHEN action == "TRANSFER" AND is_vip == "FALSE"
THEN amount <= 1000
}
STATE_CONSTRAINT transfer_limit_vip {
WHEN action == "TRANSFER" AND is_vip == "TRUE"
THEN amount <= 10000
}
// Multi-dimensional guards (amount + device trust)
STATE_CONSTRAINT device_trust_for_medium_transfer {
WHEN action == "TRANSFER" AND amount > 300
THEN device_trust >= 0.7
}
}
The deductive risk (the fact that the agent can execute rm -rf or transfer funds if prompted maliciously) is actually very common. I am working with one of the top universities in my country to write a paper about that issue. We benchmarked 118 test scenarios, 1,062 API calls across GPT-4o, Claude Sonnet, and Gemini Flash. they all fail to consistently follow their own guardrails. The results will be published by if you are interested here are the charts:
https://github.com/akarlaraytu/llm-agent-policy-enforcement
We shouldn't have to choose between crippling the agent's capabilities and just hoping we don't get targeted. And I really believe that the solution is putting a deterministic governance layer between the agent and the execution environment.
This is actually why I started building a product according to that and I just published a Show HN here. You can check it out and if you are interested I can give you credit on my platform which is dedicated to restrict unsafe behaviors and decisions of AI agents.
https://news.ycombinator.com/item?id=47501849