
Three companies posted three different job titles this month, and none of them say "AI agent security" anywhere in the headline. Look closer and they're solving the same problem: what happens when the thing making trades, reading your data, or acting on your behalf isn't a person anymore.
That's the setup for what I think is one of the more interesting AI agent security jobs trends in crypto right now. It's a discipline that's clearly forming, hiring for real, and still doesn't have an agreed name. Paradex wants a Principal Engineer, AI Products. Chainlink Labs wants a Senior Security Engineer for its Insider Trust team. TRM Labs wants a Head of Product Design who can design for humans and AI agents at the same time. Different titles, same underlying shift: agents are now users of financial systems, and almost nobody has a settled playbook for keeping that safe.
AI agent security architecture is the engineering discipline focused on protecting systems that autonomous AI agents can act inside of (trading platforms, key management systems, internal tooling) from the specific failure modes agents introduce. That's different from traditional application security, where the threat model assumes a human is on the other end of every request. Once an agent can act on your behalf, the threat model has to account for a "user" that can be prompted, tricked, or simply given more autonomy than the system was built to handle safely.
This isn't a crypto invention. Enterprise adoption of AI agents is projected to go mainstream through the rest of 2026, and prompt injection, the attack class that makes agent security necessary in the first place, is showing up far more often as agentic systems take on real-world tasks (Practical DevSecOps, 2026). Crypto is just the vertical where the stakes are the most obvious, because when an agent gets it wrong, the failure isn't a leaked record. It's a transaction that already settled.
Here's the pattern from this month's job data. Paradex is building the layer that lets AI agents trade with real leverage on a user's behalf. The job exists specifically to make sure the agent never holds the keys that would let it act unsupervised. Chainlink Labs is hiring security engineering around trust boundaries, relevant precisely because more internal systems are granting agents elevated access. TRM Labs is going further than security: its Head of Product Design role is explicitly scoped to design for human and AI-agent users of the same product.
None of these three companies used the same job title. That's not a coincidence. It's a sign the discipline is still assembling itself out of adjacent functions (security, platform engineering, product design) rather than crystallizing into one standard role. If you're waiting for a job board to filter cleanly by "AI Agent Security Engineer," you'll be waiting a while. The work is already there. The title isn't yet.
Strip away the job-posting language and the technical pattern crypto companies are converging on is specific and describable. It comes down to two things.
First, what I've started calling the agent custody boundary: the line engineers draw so an agent can initiate a trade or a payout without ever holding the credentials that would let it move funds unsupervised. In practice that means Multi-Party Computation or multisig custody, so no single party, including the agent, can authorize a transaction alone, combined with scoped, session-based permissions (patterns like Ethereum's EIP-7702) that grant an agent a narrow, time-limited set of allowed actions instead of standing access. Spending caps, counterparty whitelists, and pre-execution transaction simulation do the rest.
Second, the attack surface that boundary exists to contain: prompt injection. Because large language models don't have a hard-wired way to separate trusted instructions from untrusted data they're reading, an attacker can hide an instruction inside a webpage, a document, or on-chain metadata an agent is asked to process, and a vulnerable agent may follow it. Traditional appsec tooling doesn't reliably catch this, because the malicious input looks exactly like ordinary language, not a SQL injection string or a malformed request.
Put the two together and you get the actual job description hiding behind Paradex's title: build the boundary, assume the injection attempt is coming, and make sure the blast radius stays capped no matter what the agent is tricked into requesting.
None of the three postings I've referenced disclose a salary, which is its own signal. This market hasn't figured out its own price yet. But two adjacent numbers give a reasonable estimate. General enterprise senior AI security titles (LLM Security Architect, AI Red Teamer) are already benchmarked at $180K-$280K+ (Dexity, 2026). Separately, crypto's existing institutional security premium already pays $177K-$300K+ for engineers who combine HSM/MPC key-management skills with regulated-institution context. Fireblocks alone posted a $177K-$230K staff role for MPC-based embedded wallet work back in June.
My prediction: a crypto-specific AI agent security role doesn't average those two numbers, it compounds them. You're not choosing between "knows AI security" and "knows crypto custody." The job requires both, and neither skill set substitutes for the other. I'd expect the first disclosed salary for a role that explicitly names both to land at or above $250K, not somewhere in the middle. And if you're negotiating for one of these roles before the market has settled, that's your leverage.
Mistake 1: Hiring for the title instead of the boundary. A company that posts "AI Security Engineer" and expects a generalist to show up already knowing MPC key management, on-chain settlement irreversibility, and prompt injection defense is going to have a long search. The skill combination is rare because almost nobody's had the job yet.
Mistake 2: Treating this as a security-team-only problem. TRM Labs' approach, folding "design for AI-agent users" into a product design leadership role, is the more honest read of where this is heading. If your product is going to be used by agents, that changes onboarding, permissioning UI, and error handling, not just the backend.
Step 1: Get specific about MPC and session-based permissioning. General cloud security experience won't differentiate you. Understanding how MPC/multisig custody and scoped session permissions (EIP-7702-style patterns) actually work will.
Step 2: Learn to think like an attacker who controls the data, not the network. Traditional pentesting assumes you're probing infrastructure. Prompt injection assumes you're crafting content the agent will read and misinterpret as an instruction. Tools like Garak and PyRIT exist specifically for this kind of adversarial testing. Get familiar with them.
Step 3: Don't wait for the job title to standardize. The roles worth applying to right now are filed under Security Engineer, Principal Engineer, and even Head of Product Design. Search by function, not by title, and read the job description for the underlying problem (not holding the keys, containing prompt injection, designing for agent users) rather than the label on top of it.
AI agent security architecture is the engineering discipline focused on protecting systems that autonomous AI agents can act inside of (trading platforms, wallets, internal tools) from failure modes specific to agents, like leaked credentials, manipulated instructions, and unsupervised high-stakes actions. It combines custody engineering (keeping agents away from direct key control) with defense against prompt injection.
No crypto-native company has yet disclosed a salary specifically for an AI-agent-security role. Based on general enterprise AI security benchmarks ($180K-$280K+ for senior titles) and crypto's existing institutional security premium ($177K-$300K+ for HSM/MPC custody specialists), a crypto-specific role combining both skill sets should land at or above the higher end of that range.
The core stack is MPC or multisig custody architecture, scoped session-based permissioning (patterns like EIP-7702), and prompt injection defense and adversarial testing (tools like Garak or PyRIT). Traditional application security experience is a starting point, not a substitute. The threat model is different because the "user" is a model, not a person.
Yes. Because large language models can't reliably separate trusted instructions from untrusted data in the same input stream, an attacker can embed hidden instructions in content an agent is asked to read (a webpage, a document, on-chain metadata), and a vulnerable agent may act on them. In a crypto context, where an agent may have scoped transaction authority, this turns an ordinary data-reading task into a potential attack vector unless custody boundaries and adversarial testing catch it first.
Not yet, and possibly not soon. Right now the work is distributed across security engineering, platform engineering, and even product design postings. That's worth watching. If a single consolidated title (something like "AI Agent Security Engineer") starts appearing consistently across multiple companies, it'll be a sign the discipline has fully separated from its parent functions.
Everyone chasing "AI jobs in crypto" right now is looking at model integration and trading infrastructure. Fewer people are looking at the unglamorous, high-stakes work of making sure the agents doing that trading can't be tricked into draining an account. That's exactly the kind of gap that pays well precisely because almost nobody's positioned for it yet.
The job title hasn't caught up to the job. That's not a reason to wait. It's the opening.
Browse open Web3 roles at workingincrypto.com.