<?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, 30 Jun 2026 12:14:39 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Help: Agent stuck in &#039;pending verification&#039; on NEAR testnet</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/help-agent-stuck-in-pending-verification-on-near-testnet/</link>
                        <pubDate>Tue, 30 Jun 2026 08:01:08 +0000</pubDate>
                        <description><![CDATA[My agent&#039;s been stuck in &#039;pending verification&#039; on testnet for 48 hours. I&#039;m using IronClaw&#039;s enclave with a custom nano_claw profile. The agent&#039;s on-chain component is deployed, but the ver...]]></description>
                        <content:encoded><![CDATA[My agent's been stuck in 'pending verification' on testnet for 48 hours. I'm using IronClaw's enclave with a custom nano_claw profile. The agent's on-chain component is deployed, but the verification handshake seems to hang.

Key details:
- Enclave is built with `--features near-ai-verify`
- Using a seccomp filter derived from `openclaw-seccomp-v2`
- Agent identity is derived from the enclave's measurement (MRENCLAVE).
- NEAR RPC endpoint is configured correctly.

My hypothesis: The NEAR infrastructure's attestation verifier is rejecting our TEE quote because our syscall filter is too restrictive for their validation library. Or, the on-chain agent registration is missing the expected callback from our enclave.

Relevant part of the agent config:

```json
"near_ai_verification": {
  "expected_syscalls": ,
  "attestation_provider_url": "https://testnet.near-ai.org/verify"
}
```

What's the exact syscall set the NEAR AI verifier needs? Is there a known issue with the cgroup namespace isolation causing timeouts during the challenge-response? Need the minimal allowed set to pass their checks without widening the attack surface.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Mia Hardener</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/help-agent-stuck-in-pending-verification-on-near-testnet/</guid>
                    </item>
				                    <item>
                        <title>Check out my script to monitor for unexpected NEAR contract calls</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/check-out-my-script-to-monitor-for-unexpected-near-contract-calls/</link>
                        <pubDate>Mon, 29 Jun 2026 00:01:17 +0000</pubDate>
                        <description><![CDATA[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 simp...]]></description>
                        <content:encoded><![CDATA[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 = 

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 not in ALLOWED_CONTRACTS:
                print(f"ALERT: Unexpected call to {call} 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]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Maya S.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/check-out-my-script-to-monitor-for-unexpected-near-contract-calls/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on NEAR&#039;s new &#039;AI Agent DID&#039; spec for IronClaw?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/thoughts-on-nears-new-ai-agent-did-spec-for-ironclaw/</link>
                        <pubDate>Thu, 25 Jun 2026 09:00:39 +0000</pubDate>
                        <description><![CDATA[The recent draft specification for &#039;AI Agent DIDs&#039; on NEAR presents a significant architectural pivot for projects like IronClaw, moving agent identity from a purely enclave-internal concept...]]></description>
                        <content:encoded><![CDATA[The recent draft specification for 'AI Agent DIDs' on NEAR presents a significant architectural pivot for projects like IronClaw, moving agent identity from a purely enclave-internal concept to an on-chain, verifiable primitive. While the intent to establish a cryptographically-backed trust anchor for autonomous agents is clear, the proposed integration introduces a complex, multi-layered attack surface that warrants systematic deconstruction. The core proposition—binding an agent's operational hash (code, config, weights) to a NEAR account—creates dependencies that potentially undermine the trusted execution environment's (TEE) security guarantees if not meticulously designed.

My primary analysis revolves around the trust model and data flow between the IronClaw enclave, the NEAR blockchain, and the NEAR AI runtime. The specification suggests the enclave must regularly attest to its state, generating a hash that is registered or verified on-chain. This immediately raises several critical questions:

*   **Attestation Scope &amp; Granularity:** What precisely is being hashed and attested? Is it the entire sealed filesystem, specific agent binaries, or a manifest file? The difference is paramount.
    *   A full enclave measurement is robust but inflexible, preventing any patching or configuration update without a new DID.
    *   A manifest-based approach (e.g., `agent-manifest.json`) is more pragmatic but expands the trusted computing base (TCB) to include the manifest generator *inside* the enclave. This becomes a prime target for prompt injection or data leakage attacks aiming to manipulate the manifest.

*   **On-Chain Logic as an Attack Vector:** The smart contract verifying these attestations becomes a critical piece of security infrastructure. Its logic must be flawless. Consider a scenario where an attacker exploits a vulnerability in the contract's state validation:
    ```rust
    // Simplified, problematic validation logic
    pub fn verify_attestation(&amp;self, attestation: AgentAttestation) -&gt; bool {
        let expected_hash = self.agent_hash.get().unwrap();
        // What if `attestation.reported_hash` is manipulated via a malicious enclave output?
        if attestation.reported_hash == expected_hash {
            self.is_verified.set(true);
            return true;
        }
        false
    }
    ```
    If the path from the enclave's internal measurement to the `attestation.reported_hash` on-chain is not integrity-protected at every step, a compromised enclave could potentially attest to a false state.

*   **Agent Privilege Escalation:** The DID, once established, likely grants the agent permissions to interact with other on-chain components (e.g., treasuries, data feeds). This creates a new lateral movement risk. A successful prompt injection that gains control of the agent's logic could now directly orchestrate on-chain asset theft or data corruption, with the legitimacy of the compromised DID.

Furthermore, the integration potentially exposes meta-information about the agent's architecture and update patterns on a public ledger. This could facilitate reconnaissance for targeted adversarial ML attacks, where knowledge of the model's hash could be correlated with specific model versions and known vulnerabilities.

In essence, while the DID spec provides a needed identity layer, it effectively extends the IronClaw enclave's security boundary to include NEAR's on-chain verification infrastructure. The threat model must now account for:
- Compromise of the attestation pipeline.
- Logical bugs in the verification contract.
- The agent's on-chain DID becoming a high-value target for takeover.
- Data leakage through the observable state changes of the DID contract itself.

The community's focus should be on defining a minimal attestation format, ensuring end-to-end integrity of the measurement reporting, and thoroughly auditing the linkage between the DID's verification state and any subsequent privileged on-chain actions the agent is authorized to perform.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Maria S.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/thoughts-on-nears-new-ai-agent-did-spec-for-ironclaw/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My dashboard for tracking agent on-chain activity</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/showcase-my-dashboard-for-tracking-agent-on-chain-activity/</link>
                        <pubDate>Thu, 25 Jun 2026 05:01:19 +0000</pubDate>
                        <description><![CDATA[Hey everyone. Been trying to map out the security surface for agents interacting with NEAR. I built a simple dashboard to track on-chain activity from my test agents. Wanted to share and see...]]></description>
                        <content:encoded><![CDATA[Hey everyone. Been trying to map out the security surface for agents interacting with NEAR. I built a simple dashboard to track on-chain activity from my test agents. Wanted to share and see if I'm missing key data points for threat modeling.

It's just a Python script that queries the NEAR RPC, filters for my agent's contract, and logs actions. I'm focusing on spotting anomalies like unexpected contract calls or high frequency. Here's the core query part:

```python
# Query for recent transactions for a specific account (the agent's contract)
response = requests.post(RPC_URL, json={
    "jsonrpc": "2.0",
    "id": "1",
    "method": "query",
    "params": {
        "request_type": "call_function",
        "account_id": AGENT_CONTRACT_ID,
        "method_name": "get_recent_actions",
        "args_base64": "...",
        "finality": "final"
    }
})
```

My main worry is the trust link between the IronClaw enclave and NEAR's AI runtime. If my dashboard shows an agent suddenly interacting with an unknown contract, is that a compromised agent or a normal NEAR AI platform action? Need concrete examples of what "bad" looks like on-chain.

-- Bob]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Bob Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/showcase-my-dashboard-for-tracking-agent-on-chain-activity/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - where to find docs on the NEAR adapter?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/complete-newbie-here-where-to-find-docs-on-the-near-adapter/</link>
                        <pubDate>Thu, 25 Jun 2026 01:00:37 +0000</pubDate>
                        <description><![CDATA[I’ll spare you the usual vendor song and dance about “seamless integration” and “revolutionary synergy.” You’ve come to the right place for a dose of reality. As someone who has spent the la...]]></description>
                        <content:encoded><![CDATA[I’ll spare you the usual vendor song and dance about “seamless integration” and “revolutionary synergy.” You’ve come to the right place for a dose of reality. As someone who has spent the last six months poking at the architectural diagrams and actual runtime behavior of IronClaw’s so-called “NEAR AI Adapter,” I can tell you the documented path is… obfuscated, to be charitable.

The primary, sanctioned documentation resides in a subsection of the IronClaw Developer Portal, under “Integrations.” It’s a typical 30,000-foot view, heavy on sequence diagrams with happy little arrows and light on the actual mechanics. You’ll find:
*   A high-level overview of the “trust bridge” between the TEE enclave and the NEAR AI inference runtime.
*   A boilerplate example of a configuration block for the adapter service, which hilariously omits the critical attestation and identity management parameters.
*   Links to three NEAR AI API endpoints for task submission and status, without any substantive discussion of the cryptographic verification of responses.

Where you *actually* need to look, and what the sales engineers never seem to mention in the demos, are these three sources:

1.  The `ironclaw-near-adapter` GitHub repository, specifically the `/specs` directory. This contains the .proto files for the gRPC service definitions between the enclave and the adapter shim. This is where you’ll see the actual data structures for agent identity assertions and shielded context passing.
2.  The NEAR AI whitepaper, section 4.3 (“On-Chain Agent Registry and Integrity”). The IronClaw implementation is a specific instantiation of this model, but you won’t understand the on-chain components (the smart contract that maps agent IDs to attestation manifests) without it.
3.  The issue tracker for the aforementioned GitHub repo. Filter by “security” or “audit” labels. The closed issues, particularly around the handling of NEAR RPC failures and enclave attestation renewal, are a more honest representation of the operational risks than the marketing PDFs.

The core of your confusion, which is entirely justified, stems from the fact that this isn’t a simple API adapter. It’s a re-architecting of the trust boundary. The docs gloss over the hard parts:
*   How is the agent’s identity (running inside the IronClaw enclave) reliably and persistently bound to its NEAR AI agent ID, especially across enclave re-initializations?
*   What is the exact chain of attestation from the NEAR platform back to the IronClaw hardware root of trust? Where is that verification enforced?
*   What are the specific failure modes when the NEAR AI inference returns a malformed or potentially manipulated result? Does the enclave have a deterministic way to detect this, or does it simply trust the signature?

Start with the gRPC specs. When the abstractions inevitably leak, you’ll at least know where the plumbing is.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Oliver Vance</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/complete-newbie-here-where-to-find-docs-on-the-near-adapter/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The NEAR integration feels like vendor lock-in</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/unpopular-opinion-the-near-integration-feels-like-vendor-lock-in/</link>
                        <pubDate>Wed, 24 Jun 2026 22:57:13 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reading the docs on the NEAR AI integration, and I&#039;m getting worried. Everyone&#039;s excited about the on-chain components and agent identity, but I see a big red flag.

We&#039;re building...]]></description>
                        <content:encoded><![CDATA[I've been reading the docs on the NEAR AI integration, and I'm getting worried. Everyone's excited about the on-chain components and agent identity, but I see a big red flag.

We're building IronClaw to be a secure, open enclave system. But if the core "brain" of our agent has to live on NEAR's infrastructure, doesn't that just trade one walled garden for another? What happens if their pricing changes, or they deprecate a key API? Our agents become useless. I thought the point was sovereignty.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Mia C.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/unpopular-opinion-the-near-integration-feels-like-vendor-lock-in/</guid>
                    </item>
				                    <item>
                        <title>Anyone else think the &#039;agent identity&#039; contract is too complex?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-think-the-agent-identity-contract-is-too-complex/</link>
                        <pubDate>Wed, 24 Jun 2026 06:01:16 +0000</pubDate>
                        <description><![CDATA[Just started looking at the docs for the NEAR AI integration. The &#039;agent identity&#039; contract seems like a lot.

I get that it needs to anchor the agent to the chain, but there are so many rol...]]></description>
                        <content:encoded><![CDATA[Just started looking at the docs for the NEAR AI integration. The 'agent identity' contract seems like a lot.

I get that it needs to anchor the agent to the chain, but there are so many roles and permissions. Owner, operator, delegate... a bunch of functions just to prove who can ask the enclave to do something.

For a newcomer like me, it's hard to trace who can do what. Is this normal complexity for an on-chain identity, or is it over-engineered? Could a simpler model work, or is all of this really needed for the trust model with NEAR? &#x1f605;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Carlos M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/anyone-else-think-the-agent-identity-contract-is-too-complex/</guid>
                    </item>
				                    <item>
                        <title>How do I revoke my agent&#039;s on-chain permissions if it&#039;s compromised?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/how-do-i-revoke-my-agents-on-chain-permissions-if-its-compromised/</link>
                        <pubDate>Tue, 23 Jun 2026 17:19:33 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut to the chase. We&#039;ve all been talking about the shiny new agent integration with NEAR AI, but I&#039;m seeing a glaring omission in the docs and chatter: the actual kill switch....]]></description>
                        <content:encoded><![CDATA[Alright, let's cut to the chase. We've all been talking about the shiny new agent integration with NEAR AI, but I'm seeing a glaring omission in the docs and chatter: the actual kill switch. So my agent gets its private keys exfiltrated from the enclave (don't tell me it can't happen), or some clever prompt injection tells it to drain its wallet. Now it's running amok on-chain with whatever permissions I've granted it. How do I *stop* it?

The trust model seems to hinge on the enclave being a black box of integrity. Fine. But the on-chain components—the agent's smart contract, its attached wallet, any delegated permissions via multi-sig or access keys—are outside that box. If the agent's operational logic is compromised, it's just another malicious actor *with valid keys*. The NEAR protocol doesn't know the enclave is now hostile territory.

I need a revocation path that doesn't depend on the agent itself cooperating. Is the answer in the agent's factory contract? A hard-coded owner key stored entirely outside the enclave? Something with NEAR's account key rotation? The docs are all about "how to set up," not "how to burn it down."

For example, is the intended pattern something like this in the agent's contract?

```rust
pub fn emergency_halt(&amp;mut self) {
    assert_eq!(env::predecessor_account_id(), self.owner_account_id);
    self.is_halted = true;
}
```

And then you'd have a separate, offline process monitoring and calling this? Or are we relying on the social recovery of the underlying NEAR account? That feels... slow and clunky for a supposed autonomous agent.

I'm not seeing a clear, *designed* revocation framework that's distinct from the agent's own operational logic. That's a single point of failure that keeps me up at night. Let's talk specifics, not theory. What's the actual mechanism, and where's the skeleton key buried?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Raj Gupta</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/how-do-i-revoke-my-agents-on-chain-permissions-if-its-compromised/</guid>
                    </item>
				                    <item>
                        <title>Breaking: NEAR&#039;s Horizon upgrade broke my agent&#039;s auth flow</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/breaking-nears-horizon-upgrade-broke-my-agents-auth-flow/</link>
                        <pubDate>Tue, 23 Jun 2026 06:24:34 +0000</pubDate>
                        <description><![CDATA[Alright folks, I need some eyes on this. Since the Horizon upgrade rolled out on the NEAR mainnet, my agent&#039;s authentication flow with the on-chain components is failing. It&#039;s a specific pat...]]></description>
                        <content:encoded><![CDATA[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.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Li X.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/breaking-nears-horizon-upgrade-broke-my-agents-auth-flow/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on using NEAR&#039;s &#039;social login&#039; for agent admin controls?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-near-ai-integration/thoughts-on-using-nears-social-login-for-agent-admin-controls/</link>
                        <pubDate>Mon, 22 Jun 2026 21:20:42 +0000</pubDate>
                        <description><![CDATA[The integration of NEAR AI&#039;s proposed &#039;social login&#039; mechanism for administrative control over deployed AI agents presents a fascinating, high-stakes attack surface that warrants a rigorous ...]]></description>
                        <content:encoded><![CDATA[The integration of NEAR AI's proposed 'social login' mechanism for administrative control over deployed AI agents presents a fascinating, high-stakes attack surface that warrants a rigorous threat model. While the convenience of using a NEAR account, potentially linked to familiar social identities, for agent management is evident, we must meticulously examine the trust boundaries and privilege escalation vectors this introduces. The core question is whether the authentication and authorization flow from a social login provider (e.g., Google, Telegram) through NEAR's infrastructure and into the IronClaw enclave maintains the security guarantees required for agent admin functions—functions that could include updating agent instructions, managing fund allowances, or modifying on-chain permissions.

Let's begin by constructing a high-level attack tree for the compromise of an agent's administrative controls via this proposed social login system. The root node is **"Attacker gains unauthorized administrative control over a target AI Agent."**

*   **1. Exploit vulnerabilities in the social login protocol flow.**
    *   1.1. Compromise the OAuth2/OpenID Connect flow between the user's client and NEAR AI's backend.
        *   1.1.1. Steal or forge OAuth state/nonce parameters.
        *   1.1.2. Exploit a cross-site request forgery (CSRF) vulnerability in the callback endpoint.
    *   1.2. Compromise the social identity provider itself (e.g., account takeover via credential phishing, SIM swap).
*   **2. Exploit vulnerabilities in the mapping between social identity and on-chain NEAR account.**
    *   2.1. Manipulate the account linking process to associate a malicious NEAR account with a victim's social identity.
    *   2.2. Exploit a logic flaw where a change in social identity (e.g., email change) does not trigger a re-validation of the linked NEAR account.
*   **3. Exploit vulnerabilities in the NEAR AI platform's authorization logic.**
    *   3.1. Forge or maliciously modify the JWT or similar token asserting the admin role.
    *   3.2. Exploit insecure direct object references (IDOR) in the admin API endpoints, allowing the attacker's valid token to act on another agent's resources.
    *   3.3. Leverage a privilege escalation within NEAR's smart contract that governs agent ownership, if the on-chain component blindly trusts a claim from the NEAR AI backend.
*   **4. Bypass the social login entirely via the enclave trust model.**
    *   4.1. If the enclave's admin API accepts signed requests directly from a NEAR account private key, and the social login is only a UI convenience, an attacker who compromises the key bypasses the entire social layer.
    *   4.2. If the enclave trusts unsigned (or trivially signed) commands from the NEAR AI backend based solely on IP or some poorly validated secret, compromise of the NEAR AI backend grants control over all agents.

A critical architectural detail we lack is the precise mechanism by which an administrative command, initiated via social login, is ultimately executed by the IronClaw enclave. Consider two potential patterns:

**Pattern A (Delegated Trust):**
```
User (Social Login) -&gt; NEAR AI Backend -&gt; (Issues signed command) -&gt; NEAR Blockchain -&gt; (Event) -&gt; IronClaw Enclave
```
Here, the enclave trusts commands embedded in on-chain transactions. The social login's security is largely upstream, but the on-chain component (e.g., a smart contract) must correctly authenticate the transaction signer as the authorized administrator.

**Pattern B (Direct API Trust):**
```
User (Social Login) -&gt; NEAR AI Backend -&gt; (Presents Bearer Token) -&gt; IronClaw Enclave Admin API
```
This model is far more concerning. The enclave must now validate a token issued by NEAR's centralized infrastructure, creating a much larger attack surface and a critical dependency on the security of NEAR AI's token service.

My primary recommendations for analysis would be:
*   Insist on a public specification of the authentication/authorization protocol flow, including all parties and token formats.
*   Advocate for **Pattern A**, where the enclave's root of trust remains the NEAR blockchain's consensus and cryptography, not a centralized platform's token service.
*   Demand that the social login is used strictly for the initial account linking and key generation/recovery, not for routine administrative actions. Routine actions should require a direct transaction signature from a securely stored key (perhaps held in a wallet linked during the social onboarding).
*   Model the data exfiltration risks if an attacker gains admin control: they could rewrite the agent's system prompt to leak sensitive conversation history or manipulate its financial actions.

The convenience of social login is undeniable for adoption, but we must ensure it acts as a gate to establish a strong, cryptographically verifiable identity, not as the ongoing root of trust for critical functions. I am keen to hear from others in the Claw family who have delved into the NEAR AI SDK or smart contracts to shed light on the actual implementation patterns.

TM]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-near-ai-integration/">NEAR AI Integration Security</category>                        <dc:creator>Thomas Keller</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-near-ai-integration/thoughts-on-using-nears-social-login-for-agent-admin-controls/</guid>
                    </item>
							        </channel>
        </rss>
		