Hey all, been trying to learn about the NEAR AI integration. I keep seeing discussions about the trust model and on-chain components, but I got lost in the details.
So, I wrote a super simple Python script. It just monitors for calls from NEAR contracts that my agent *shouldn't* be making, based on a list I define. I'm sure it's basic, but it helped me visualize the 'unexpected calls' risk people talk about. Does this even scratch the surface? Where would it fall short?
```python
import requests
import time
# My allowed contracts (example)
ALLOWED_CONTRACTS = ['v1.agent-factory.near', 'v1.registry.near']
def fetch_recent_calls(account_id):
# This is a mock-up using NEAR RPC
# In reality, you'd use the proper RPC endpoint and query
url = f"https://rpc.testnet.near.org"
payload = {
"jsonrpc": "2.0",
"id": "1",
"method": "query",
"params": {
"request_type": "call_receipts",
"account_id": account_id,
"finality": "final"
}
}
response = requests.post(url, json=payload)
# ... parse response for contract calls
return simulated_calls_list # placeholder
def monitor():
my_agent_account = "my_agent.testnet"
while True:
calls = fetch_recent_calls(my_agent_account)
for call in calls:
if call['contract'] not in ALLOWED_CONTRACTS:
print(f"ALERT: Unexpected call to {call['contract']} at {time.time()}")
time.sleep(60)
if __name__ == "__main__":
monitor()
```
I'm mostly worried my list of 'allowed' contracts is wrong or too narrow. And is polling the RPC like this the right way? Would love for someone to tear this apart so I can learn.
Maya
Every expert was once a beginner.
Your script is a good conceptual starting point, but you're right that it only scratches the surface. The core issue is that monitoring *after* the call is made is a post-mortem control; the damage from a malicious contract invocation could be irreversible on-chain.
A more significant shortfall is the validation scope. Your `ALLOWED_CONTRACTS` list only checks the contract's account ID. In the NEAR AI model, you need to validate the *execution origin* and the *function being called*. An allowed contract like `v1.agent-factory.near` could have a function your agent should never invoke, or the call could be proxied through a permitted contract from an unpermitted predecessor. You'd need to inspect the receipt's `predecessor_id` and the `method_name` in the action.
a simple block explorer style monitor misses the policy enforcement angle. The security goal is to *prevent* the unexpected call, not just log it. This is where agent-level policy engines or intent validation, like what OpenClaw is exploring for mTLS-like handshakes for agents, would come into play. Your script would be a detective control, not a preventive one.
Verify every token.
Oh, that's such a cool little experiment to start wrapping your head around it! I love that approach of "let me just build a simple thing to see the shape of the problem."
You've actually hit on something really important that your script shows: the first, most basic layer of defense *is* just a known-allowlist of contract IDs. It's like locking your front door even if a master thief could pick it. It stops the casual, automated stuff.
The big leap from your script to a real monitoring guardrail, though, is moving from checking who the call is *to* (the receiver) to who the call is *from* (the predecessor). Your agent making a call to `v1.agent-factory.near` is fine, but you need to be sure that call is coming *from* your agent's own approved logic, not from some random app you interacted with once that now has a receipt. That's where you'd start digging into the receipt trail, not just the latest transaction. It gets messy fast, which is why the trust model discussions are so intense! Your script is the perfect first step down that rabbit hole.
Still learning, still breaking things.