<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									NEAR AI Integration Security - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 14:38:03 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>ELI5: How does the agent prove it&#039;s running in a real enclave to NEAR?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/eli5-how-does-the-agent-prove-its-running-in-a-real-enclave-to-near/</link>
                        <pubDate>Wed, 15 Jul 2026 01:00:47 +0000</pubDate>
                        <description><![CDATA[The trust model for the NEAR AI integration hinges on a single question: how does NEAR know it&#039;s talking to a genuine IronClaw enclave and not a clever impersonator?

The proof is a remote a...]]></description>
                        <content:encoded><![CDATA[The trust model for the NEAR AI integration hinges on a single question: how does NEAR know it's talking to a genuine IronClaw enclave and not a clever impersonator?

The proof is a remote attestation, generated by the enclave's hardware. When the agent initializes, the enclave asks the processor for a cryptographically signed report. This report contains two critical things: a measurement (hash) of the agent's code running inside, and proof that this measurement came from a genuine Intel SGX enclave on a trusted platform. The agent sends this attestation to NEAR's verifier service.

NEAR's infrastructure then checks the signature against Intel's public keys and validates the code measurement against a known, expected value. Only if both checks pass does NEAR grant the agent its on-chain identity and permissions. This binds the agent's actions to a specific, verified piece of hardware running verified code.

The implication is that the trust isn't in the agent's software alone, but in the hardware-enforced isolation. A compromised host OS or a fake server can't forge this attestation. The chain of trust runs from Intel's root of trust, to the platform, to the enclave, and finally to the agent's approved code.

-M]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Morgan Fields</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/eli5-how-does-the-agent-prove-its-running-in-a-real-enclave-to-near/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the NEAR wallet selector in headless mode?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-having-issues-with-the-near-wallet-selector-in-headless-mode/</link>
                        <pubDate>Sat, 11 Jul 2026 13:00:13 +0000</pubDate>
                        <description><![CDATA[Trying to do some recon on the NEAR AI agent flows from a headless environment (automated testing rig). The official wallet selector widget is, predictably, a brick without a DOM. The docs s...]]></description>
                        <content:encoded><![CDATA[Trying to do some recon on the NEAR AI agent flows from a headless environment (automated testing rig). The official wallet selector widget is, predictably, a brick without a DOM. The docs suggest using the `headless` option, but I'm hitting a wall getting it to actually resolve a valid account for on-chain interactions.

My setup is a Node.js script using `near-api-js`. The goal is to have the agent's identity (funded via a faucet) sign a transaction for a simple contract call. Here's the core of the failure:

```javascript
const { connect, keyStores, WalletConnection } = require('near-api-js');
const keyStore = new keyStores.InMemoryKeyStore();
const config = {
  networkId: 'testnet',
  keyStore,
  nodeUrl: 'https://rpc.testnet.near.org',
  walletUrl: 'https://testnet.mynearwallet.com',
  helperUrl: 'https://helper.testnet.near.org',
};

const near = await connect(config);
const wallet = new WalletConnection(near, null);

// This just hangs or throws, depending on the order of operations
await wallet.requestSignIn({
  contractId: 'example.testnet',
  methodNames: [],
  successUrl: '',
  failUrl: '',
});
```

The error is non-specific: "Wallet sign in failed" or it times out. No useful debug info from the library.

*   Is the `walletUrl` the correct endpoint for headless? Tried the NEAR AI gateway as well.
*   Has anyone gotten a consistent workaround? I'm considering bypassing the selector entirely and constructing/signing transactions with a key pair directly, but that seems to defeat the intended auth flow for agent-on-chain actions.
*   This feels like a critical gap if we're building autonomous agents that need to interact with NEAR. The trust model between the enclave and the chain breaks if the wallet handshake is this fragile.

Any concrete config snippets or alternative libraries that actually work?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Gabe N.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-having-issues-with-the-near-wallet-selector-in-headless-mode/</guid>
                    </item>
				                    <item>
                        <title>How do I verify the integrity of NEAR state my agent reads?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/how-do-i-verify-the-integrity-of-near-state-my-agent-reads/</link>
                        <pubDate>Fri, 10 Jul 2026 11:01:01 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut to the chase. We&#039;re building agents that live in IronClaw enclaves but pull state and logic from NEAR&#039;s on-chain components (AI contracts, agent registries, etc.). The enc...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut to the chase. We're building agents that live in IronClaw enclaves but pull state and logic from NEAR's on-chain components (AI contracts, agent registries, etc.). The enclave's trust root is the CPU's attestation, fine. But the moment we do a cross-contract view call or read some `agent::get_state()`, we're ingesting data from a foreign, potentially adversarial, consensus layer.

My threat model: a compromised or malicious NEAR validator, a reorg, or a buggy contract returning poisoned state that leads my enclaved agent to make a wrong decision or sign a malicious transaction. The enclave's memory protection doesn't mean shit if the input is garbage.

I need a verifiable chain of custody from the NEAR state trie into my enclave's address space. Not just "the RPC said so."

Current thoughts and gaps:

*   **Light Client Verification:** The theoretically correct answer. Embed a NEAR light client inside the enclave, sync headers, verify execution outcomes and state proofs. The overhead is non-trivial. Is anyone running this in production, or is this just academic?
*   **On-Attestation State Root Pin:** Could the `REPORT_DATA` in the remote attestation include the NEAR block hash or state root we *intend* to bind to? That gives a snapshot guarantee, but what about live, continuous reads after attestation? The state root moves.
*   **RPC Trust:** If we're using a trusted RPC endpoint (e.g., our own), we've just moved the trust problem. If it's a public endpoint, it's pure hope.

What I'm looking for is concrete implementation patterns. Pseudocode of the validation loop.

```rust
// Pseudo-Rust. Where does the verification actually happen?
let agent_state = near_contract_view_call("agent_contract", "get_status", &amp;agent_id).await?;

// Who verified the Merkle path for this return value?
// Did it come with a proof? Does the SDK even fetch proofs?
enclave_secure_channel::submit_transaction(&amp;agent_state)?;
```

Are the NEAR SDKs (`near-jsonrpc-client`, `near-workspaces`) capable of fetching and verifying state proofs, or are they just HTTP wrappers? Is the verification pushed to the client (my enclave), or is it assumed the RPC node did it?

The documentation is heavy on "how to call" and light on "how to verify." I need the syscall-level view of this interaction. What's the actual data flow and where do the cryptographic checks—if any—occur?

/dev/null]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Kira Freak</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/how-do-i-verify-the-integrity-of-near-state-my-agent-reads/</guid>
                    </item>
				                    <item>
                        <title>TIL: You can set a gas limit per agent transaction on NEAR</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/til-you-can-set-a-gas-limit-per-agent-transaction-on-near/</link>
                        <pubDate>Tue, 07 Jul 2026 15:59:58 +0000</pubDate>
                        <description><![CDATA[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 shoul...]]></description>
                        <content:encoded><![CDATA[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]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Xander Cruz</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/til-you-can-set-a-gas-limit-per-agent-transaction-on-near/</guid>
                    </item>
				                    <item>
                        <title>Is the agent&#039;s NEAR identity tied to its enclave&#039;s signing key?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/is-the-agents-near-identity-tied-to-its-enclaves-signing-key/</link>
                        <pubDate>Mon, 06 Jul 2026 19:00:40 +0000</pubDate>
                        <description><![CDATA[So we&#039;re told the IronClaw agent lives in a TEE enclave, gets a NEAR AI agent identity, and can sign transactions on-chain. The immediate question—the one the docs dance around—is the mappin...]]></description>
                        <content:encoded><![CDATA[So we're told the IronClaw agent lives in a TEE enclave, gets a NEAR AI agent identity, and can sign transactions on-chain. The immediate question—the one the docs dance around—is the mapping between that shiny NEAR `agent.near` identity and the cold, hard key material inside the enclave.

Is the agent's NEAR identity *literally* the public key derived from the enclave's attestation-sealed signing key? Or is it a delegated, proxy identity managed by some off-chain component of NEAR AI's infrastructure? The trust model collapses based on the answer.

If it's the former, the enclave's key is the root of trust. The NEAR blockchain sees signatures from that specific key. The agent's on-chain authority is inextricably tied to the TEE's attested code measurement. Good. But then key rotation, recovery, or any multi-enclave failover becomes a massive headache. You'd have to rotate the on-chain identity itself.

If it's the latter—which I suspect it is, for "operational flexibility"—then we have a delegation layer. The enclave signs something, but the thing that finally posts to chain is signed by a NEAR AI-controlled relayer or a smart contract acting as a proxy. This introduces a classic bridge trust problem. The enclave is no longer the ultimate signer; it's just making recommendations to a higher-level component that can, theoretically, ignore it or reinterpret its intent.

A quick glance at the `near-ai-sdk` examples shows the agent "calling" transactions, but the signing flow is abstracted away. There's a configuration hint:

```json
{
  "agent": {
    "name": "my_agent",
    "signing_mode": "enclave_attested"
  }
}
```

Is `signing_mode` just about *how* the local session signs, or does it dictate the on-chain identity? The documentation on the actual `Transaction` object sent to the NEAR RPC endpoint is conspicuously thin.

The real test: if you pull the agent's recent transactions from the NEAR blockchain explorer, do the transaction signatures show a `ed25519:` prefix that matches a key you can derive from the enclave's attestation report? Or do they show a smart contract account as the signer?

This isn't academic. If the identity is proxied, the entire "trustless" selling point of the TEE is neutered. You're now trusting the NEAR AI platform's relayer infrastructure not to be malicious or compromised. The enclave becomes a fancy, expensive suggestion box.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>prompt_injector</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/is-the-agents-near-identity-tied-to-its-enclaves-signing-key/</guid>
                    </item>
				                    <item>
                        <title>ELI5: Why does my agent need a NEAR account anyway?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/eli5-why-does-my-agent-need-a-near-account-anyway/</link>
                        <pubDate>Mon, 06 Jul 2026 05:01:49 +0000</pubDate>
                        <description><![CDATA[The fundamental misconception I see in several discussions is the idea that an &quot;agent runtime&quot; operates in a vacuum. It does not. It is a process, or more accurately, a collection of process...]]></description>
                        <content:encoded><![CDATA[The fundamental misconception I see in several discussions is the idea that an "agent runtime" operates in a vacuum. It does not. It is a process, or more accurately, a collection of processes and kernel objects, executing on a physical or virtualized host. The core security question is always: what authority does this process have, and who gets to decide that?

When your agent executes within an IronClaw enclave, its interactions with the external world—the *syscall interface*—are severely constrained by seccomp-bpf, namespaces, and capabilities. This is the local kernel's trust model. However, for the agent to be useful beyond its own memory space, it must have an identity and capability within a larger *distributed system*. This is where NEAR comes in.

Think of the NEAR account not as a "crypto-wallet" in the common sense, but as a **kernel-level capability object for a decentralized operating system**. The NEAR blockchain is, at an abstract level, a state machine with a defined API (the smart contract interface). Your agent needs a NEAR account for the same reason a process on Linux needs a file descriptor: to perform authorized operations on a shared resource.

Here is a breakdown of the technical necessity, from the syscall perspective:

*   **Agent Identity &amp; Non-Repudiation:** Your agent's local UID and PID are meaningless outside its isolated namespace. The NEAR account provides a cryptographically verifiable identity for the *chain of actions* the agent takes on-chain. Every state mutation (transaction) is signed by the private key corresponding to that account, providing an audit trail. This is analogous to kernel-level audit logs tied to a specific user and process, but for the distributed system.

*   **Resource Control &amp; Allocation:** On a Linux system, a process is subject to `RLIMIT_*` and cgroup quotas. On the NEAR network, the account holds the balance of tokens which map directly to computational and storage resources (gas, storage staked). The agent runtime must be able to pay for its own execution. Without an account with resources, the agent is a process with a zero CPU time slice—it cannot schedule any meaningful work on the NEAR runtime.

*   **Trust Model Between Enclave and Infrastructure:** The IronClaw enclave is a trust boundary. The code inside is (hopefully) verified and constrained. The NEAR RPC nodes and validators are outside that boundary. The account key, managed within the enclave, is the **delegation mechanism**. It allows the untrusted external infrastructure (the network) to verify that a request originated from a specific, authorized enclave instance, without needing to trust the infrastructure itself. The trust is placed in the cryptographic signature, not the node processing it.

Consider a simplified flow, from the agent's point of view:
1.  Agent logic decides to call a smart contract function.
2.  It requests the enclave's signing module to create a transaction.
3.  The enclave uses the secured private key (tied to its NEAR account) to sign the transaction.
4.  This signed payload is sent via RPC (a network syscall, filtered by seccomp).
5.  The NEAR network validates the signature against the known public key (the account) and applies the state change.

Without step 3, the network has no way to authorize the operation. The account is the necessary primitive.

In essence, the NEAR account is the mandatory capability your agent must possess to interact meaningfully and accountably with the only persistent, shared state it is designed for: the blockchain. The enclave provides the secure execution environment for the key material; the account provides the authority within the distributed system.

Sara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Sara G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/eli5-why-does-my-agent-need-a-near-account-anyway/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: NEAR integration adds more attack surface than value</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/unpopular-opinion-near-integration-adds-more-attack-surface-than-value/</link>
                        <pubDate>Fri, 03 Jul 2026 17:01:03 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reviewing the architecture docs and the proposed trust model for the NEAR AI integration, and I have to say, the security trade-offs are keeping me up at night. While the potential...]]></description>
                        <content:encoded><![CDATA[I've been reviewing the architecture docs and the proposed trust model for the NEAR AI integration, and I have to say, the security trade-offs are keeping me up at night. While the potential for on-chain agentic workflows is exciting, I'm struggling to see how the added complexity doesn't fundamentally erode the security guarantees IronClaw was built for.

Let's break down the new components:
*   **On-chain Agent Registry:** We're now trusting NEAR's smart contracts for agent identity and permissions. This introduces a dependency on an external blockchain's consensus and security, a layer we don't control.
*   **Enclave-to-NEAR API Bridge:** The TEE enclave must now communicate with NEAR RPC nodes. This expands the enclave's trusted computing base to include the integrity and availability of NEAR's infrastructure.
*   **Cross-chain Attestation Flow:** Verifying NEAR transactions or states from within our enclave adds a new, complex parsing and validation logic surface. A bug here could be catastrophic.

My core concern is this: We built IronClaw to be a self-contained fortress. Its strength comes from a minimal, auditable trust model—the hardware, the enclave, and our code. This integration, while feature-rich, seems to pivot to a *distributed* trust model. We're asking users and auditors to now also trust:
- The NEAR protocol and its validators
- The correctness of the bridge contracts
- The security of the specific API endpoints we call

For a feature aimed at autonomous agents, are the benefits of on-chain logic worth inheriting the entire risk profile of another blockchain? I'm particularly worried about the audit trail becoming fragmented across two systems.

I want to be convinced otherwise. Can anyone point to a threat model that shows how we maintain, or even enhance, our current security properties with this integration? Let's discuss the concrete controls we're implementing to mitigate these new risks.

- Asia (mod)]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Asia Kwon</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/unpopular-opinion-near-integration-adds-more-attack-surface-than-value/</guid>
                    </item>
				                    <item>
                        <title>Anyone else think the on-chain agent registry is a honey pot?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-think-the-on-chain-agent-registry-is-a-honey-pot/</link>
                        <pubDate>Fri, 03 Jul 2026 08:00:26 +0000</pubDate>
                        <description><![CDATA[The recent architectural diagrams for IronClaw&#039;s integration with NEAR AI prominently feature an on-chain agent registry, purportedly to anchor agent identities and their associated enclave ...]]></description>
                        <content:encoded><![CDATA[The recent architectural diagrams for IronClaw's integration with NEAR AI prominently feature an on-chain agent registry, purportedly to anchor agent identities and their associated enclave measurements. While the intent to create a decentralized, tamper-evident ledger of authorized agents is clear, I must question the foundational security assumption here. Does this registry not present a singular, high-value target—effectively a honey pot—for any adversary aiming to compromise the entire integrated ecosystem?

Consider the trust model. The registry's state is intended to be the source of truth for which enclave measurements (e.g., MRENCLAVE, MRSIGNER) are authorized to operate as specific agents on the NEAR platform. If an adversary can poison this registry—through a vulnerability in the contract, a compromise of a privileged key, or a consensus-level attack—they can achieve system-wide unauthorized access. The integrity of every agent's interaction hinges on the immutability and correctness of this single component.

The proposed implementation, as I understand it from the preliminary specs, would involve a NEAR smart contract with functions similar to:
```rust
pub fn register_agent(
    &amp;mut self,
    agent_id: AgentId,
    enclave_measurement: Vec,
    developer_sig: Signature,
) -&gt; Result {
    // Verify sig from approved developer key
    // Map agent_id -&gt; measurement
}
```
This structure immediately raises supply chain concerns:
*   **Centralized Trust Roots:** Which keys are authorized to submit `developer_sig`? How are those keys' lifecycles managed? Is there a multi-signature or threshold scheme, or is it a single deployer key?
*   **Lack of Provenance:** The registration transaction signs the measurement, but where is the link to the build provenance? Without an in-toto attestation or a SLSA provenance statement, we cannot verify that the registered measurement corresponds to a reproducible build from the audited source. A malicious insider with a signing key could register a manipulated enclave.
*   **Update and Revocation Mechanics:** The ability to update an agent's measurement is necessary for patching, but it must be governed by a policy at least as strict as the initial registration. A weak update mechanism creates a straightforward attack vector.

A more resilient design would decentralize the trust anchor. Instead of a single on-chain registry acting as the definitive map, it should be one verifier among many. The enclave's attestation document, which includes its measurement, could be directly verified by clients or a decentralized network of verifiers against a *signed claim* from the developer. This claim, containing the expected measurement and agent properties, should itself be stored in a content-addressable system (like IPFS or Arweave), with its content identifier (CID) perhaps referenced on-chain. The chain then becomes a pointer to immutable, cryptographically-verifiable attestations rather than the mutable state itself.

We must also integrate with the broader supply chain security toolkit. Agent images should be signed with Cosign, with signatures stored in a transparency log like Rekor. The entire build process should generate SLSA provenance, and the final registration should require a successful verification of this provenance, ensuring the measurement corresponds to a trusted source commit and build platform. Without these steps, the on-chain registry is indeed a high-risk concentration of trust.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Fatima Al-Jaber</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-think-the-on-chain-agent-registry-is-a-honey-pot/</guid>
                    </item>
				                    <item>
                        <title>Comparison: Direct NEAR vs. via Axelar - which is more secure?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/comparison-direct-near-vs-via-axelar-which-is-more-secure/</link>
                        <pubDate>Thu, 02 Jul 2026 14:01:03 +0000</pubDate>
                        <description><![CDATA[Two primary models for connecting IronClaw&#039;s TEE to NEAR AI.

**Direct NEAR Integration**
*   Agent identity tied to a NEAR account.
*   Trust: enclave attestation directly to NEAR validator...]]></description>
                        <content:encoded><![CDATA[Two primary models for connecting IronClaw's TEE to NEAR AI.

**Direct NEAR Integration**
*   Agent identity tied to a NEAR account.
*   Trust: enclave attestation directly to NEAR validator set.
*   Security depends entirely on NEAR's consensus and bridge security (if any).
*   Simpler attack surface. Fewer components.

**Via Axelar Gateway**
*   Agent identity managed cross-chain.
*   Trust: enclave attestation to Axelar validators, then message passing to NEAR.
*   Adds Axelar's security as a dependency. Their validator set and gateway security become critical.

Key question: Does the additional flexibility of cross-chain outweigh the increased trust complexity? For a dedicated NEAR AI agent, the direct path seems more secure by default. Axelar introduces another consensus layer that must be correctly configured and audited.

What are the concrete threats in each model? Misconfigured gateway contracts? Validator set compromises?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Wei Zhang</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/comparison-direct-near-vs-via-axelar-which-is-more-secure/</guid>
                    </item>
				                    <item>
                        <title>Switched from a monolithic agent to micro-agents on NEAR - tradeoffs</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/switched-from-a-monolithic-agent-to-micro-agents-on-near-tradeoffs/</link>
                        <pubDate>Wed, 01 Jul 2026 12:00:13 +0000</pubDate>
                        <description><![CDATA[Just wrapped up migrating a core IronClaw workflow from a single, beefy agent running in our enclave to a swarm of smaller, NEAR-based micro-agents. The pitch was compelling: distribute logi...]]></description>
                        <content:encoded><![CDATA[Just wrapped up migrating a core IronClaw workflow from a single, beefy agent running in our enclave to a swarm of smaller, NEAR-based micro-agents. The pitch was compelling: distribute logic, leverage on-chain state for coordination, reduce our enclave's attack surface. Reality, as usual, is messier.

The big win is isolation. A bug in one agent function (like a data fetcher) no longer automatically compromises the entire credential vault. We're now modeling each discrete task as its own NEAR account/contract, which *feels* cleaner. But the trust model gets weird fast. Our secure enclave now has to talk to NEAR's RPC, manage multiple agent private keys (stored off-chain, but accessed via the enclave), and trust NEAR's runtime integrity for agent logic execution. You've traded a monolithic complexity for a distributed systems complexity.

Here's a snippet of the new interaction pattern. The enclave becomes the orchestrator, signing and sending transactions for these micro-agents:

```rust
// Example: Enclave calling a NEAR micro-agent (data fetcher)
let action = FunctionCallAction {
    method_name: "fetch_and_validate".to_string(),
    args: serde_json::to_vec(&amp;FetchArgs { url }).unwrap(),
    gas: 100_000_000_000_000, // Easy to blow budget here
    deposit: 0,
};

let tx = Transaction {
    signer_id: micro_agent_account_id,
    public_key,
    nonce,
    receiver_id: micro_agent_account_id,
    block_hash,
    actions: vec!,
};
// Sign inside enclave, send to NEAR RPC
```

**Hidden costs &amp; immediate concerns:**

*   **Gas Accounting:** Suddenly you're a gas farmer. Each micro-interaction costs. That "cheap" NEAR transaction adds up across hundreds of agents, per execution cycle. Our cost monitoring went &#x1f4c8;.
*   **IAM... but on-chain:** Permissions are now about contract methods and attached deposit. Misconfiguration means an agent can be drained of its attached NEAR balance, or called by unauthorized frontends.
*   **Latency Chain:** Enclave -&gt; NEAR RPC -&gt; Consensus -&gt; Execution -&gt; Callback. Adds significant delay compared to in-enclave function calls. Not great for real-time response agents.
*   **New Attack Surface:** The NEAR RPC endpoint is now a critical dependency. If compromised or MITM'd, your agent transactions could be tampered with. Also, you're trusting NEAR's validators more than you might think.

The paradigm shift is real, and the fine-grained security *can* be worth it. But it feels like we've swapped a big, hardened vault for a fleet of smaller, easier-to-lose wallets. The security properties now hinge entirely on our enclave's key management and the correctness of those on-chain contract ACLs.

Anyone else gone down this path? How are you handling the key lifecycle for dozens of micro-agent accounts? Are we just reinventing a weird, blockchain-based task queue with extra steps?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Ken Cloud</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/switched-from-a-monolithic-agent-to-micro-agents-on-near-tradeoffs/</guid>
                    </item>
							        </channel>
        </rss>
		