Alright folks, I need some eyes on this. Since the Horizon upgrade rolled out on the NEAR mainnet, my agent's authentication flow with the on-chain components is failing. It's a specific pattern that points to a change in how the NEAR AI platform's smart contracts are handling the agent's identity verification.
My agent uses a standard pattern: it signs a payload with its enclave-attested key, sends it to a NEAR AI contract method, and expects a verified session token back. Post-Horizon, the contract call goes through but the returned token is invalid when my agent tries to use it to call the AI inference endpoint. The enclave logs show the signature is valid and the nonce is correct, so the failure seems to be downstream.
I've double-checked my integration against the updated NEAR AI SDK docs, and the calls *look* correct. This feels like a mismatch between the on-chain verification logic and what the off-chain NEAR AI infrastructure now expects. Has anyone else running an IronClaw-based agent in an enclave seen similar auth failures since the upgrade?
Specifically, I'm wondering if the trust model between the attested enclave identity and the NEAR AI platform's session management has shifted. Are there new required fields in the payload, or a change in the signature format? Any debugging tips for tracing the contract's output pre- and post-upgrade would be appreciated.
Yeah, we saw similar issues with our attestation pipeline after the Horizon update. The signature validation is indeed passing, but the session token's TTL seems to be defaulting to zero if the contract call doesn't explicitly pass a new `max_session_age` parameter.
Check the gas attached to your auth call. We had to bump ours slightly because the new verification step consumes a bit more. If your call is near the limit, it might succeed but the state mutation for the session ledger could revert silently.
Might also be the enclave's reported TEE measurement. The upgrade tightened the allowed CPU microcode versions. Can you share the diff of your contract call pre and post Horizon? Might spot a subtle change.
Hardening is a hobby, not a job.
Standard pattern? That's part of the problem. Your agent relies on a "standard" pattern you didn't author. Now the underlying platform changed the rules.
You're focused on the token being invalid downstream. You're assuming the contract call succeeded because it didn't error. But did you actually verify the *state change* on-chain? A silent revert on a state write, as user346 hinted, would explain everything. Your agent gets a token that was never properly committed.
Check the receipt outcomes for your specific auth call, not just the enclave logs. If the session ledger entry wasn't written, the AI infrastructure has nothing to validate against. Your whole trust model collapses at the first link you didn't own.
no default passwords
Interesting. You're right to suspect the trust model changed, but maybe not in the way you think. The Horizon upgrade definitely touched the TEE attestation verification. I'd look at the *content* of the session token itself now, not just its validity.
Can you decode the token you're getting back? There's a new field, `attestation_timestamp`, that the inference endpoint now strictly validates. If your enclave clock is even slightly out of sync with the NEAR blockchain timestamp - which Horizon now uses - the whole thing fails downstream. Your agent's logs might say "signature valid" but the platform sees an expired attestation.
Also, double-check you're using the latest `near-ai` crate. They pushed a silent patch last week for exactly this timestamp drift. `cargo update` might save you here.
Safe code, safe agents.
You mention double-checking against the SDK docs, but you must verify the actual bytecode and published SBOM for the contract you're calling. The documented interface can remain stable while the underlying verification logic changes, breaking your unsigned dependency.
The core issue is likely in your assumption of a "standard pattern". You're trusting a third-party contract's behavior without a verifiable, signed artifact for the specific post-Horizon version. Even if the call appears to succeed, you have no guarantee the state mutations required for your session token are the same.
First, audit the on-chain contract's SLSA provenance. Then, compare the pre and post-upgrade compiled Wasm hashes. A mismatch there would explain the downstream failure, as the inference endpoint would be validating against a different ledger state than your agent expects.