Who Holds the Authority When AI Agents Pay for Their Own GPU Compute?

I recently wrote about a problem with how AI agents get authorized. Handing an agent a copy of an API key gives it a bearer credential, proof that whoever holds it is allowed to knock on the door, but it says nothing about what they're allowed to do once they're inside, or how fast you can throw them back out if something goes wrong. That argument was built around centralized infrastructure: API keys, OAuth tokens, and JWTs. Decentralized GPU compute takes the exact same problem and raises the stakes considerably, because the credential in question is a wallet, and the actions it authorizes can't be undone once they're confirmed. Agents Are Already Deploying Directly Onto Decentralized Compute Nosana, a decentralized GPU marketplace built on Solana, already has developers (ElizaOS and Mastra among them) deploying full agent frameworks directly onto its network, rather than a traditional cloud provider. The agent runs the workload, and payment for the compute it used moves through Solana smart contracts handling job posting, matching, and settlement. Circle's own agentic payments infrastructure describes the broader pattern plainly: agents transacting at high frequency and extreme granularity, executing large volumes of sub-cent payments per minute without a human approving each one. Compute is becoming something agents buy for themselves, not something a person provisions on their behalf. The Same Bearer Problem, With Real Money and No Undo Button A wallet keypair held by an agent is a bearer credential in its purest form. Whoever holds the private key can sign a transaction up to the full balance behind it, and there's no equivalent of a support line to call once that transaction confirms. A leaked API key can be rotated. A misused OAuth token can be revoked, awkwardly, across whatever systems it touched. A confirmed transaction on Solana is final. The Replit incident I wrote about previously, where an agent deleted a production database during an explicit freeze, happened because a system prompt was treated as an enforced boundary when it was actually just a request the agent was free to ignore. Give that same category of agent a funded wallet on a decentralized compute network, and the equivalent failure isn't a deleted database. It's funds gone, permanently, to whatever the agent decided to sign for. Solana Already Has the Primitive, It's Just Not Being Used This Way Here's what makes this genuinely solvable. Solana's own SPL Token program already supports delegation. An owner can approve another account to spend up to a specified amount from a token account without ever handing over custody of the funds. The delegate can transfer up to the approved cap and nothing more, and the owner can revoke that approval at any time in a single instruction, immediately zeroing out the delegate's remaining allowance. That's most of the mandate model I described in the API key piece: a capped, revocable, and non-custodial spending authority, already live on the same chain Nosana runs on. Solana's newer Subscription Delegation Program closes a real gap in the basic version. A token account can only have one active delegate at a time under the original design, which breaks down fast if an agent needs separate scoped budgets for separate jobs or separate compute providers. The subscription program gives each user-and-token pair its own program-controlled authority, so a single wallet can support several simultaneous, independently capped spending arrangements instead of being limited to one delegate for everything. Comparison of an agent holding full wallet custody versus a capped, revocable delegated spending authority What's Still Missing Spending caps and instant revocation are two of the seven properties a full authority model needs. They don't cover the rest. A delegated token allowance says how much an agent can spend. It says nothing about which specific compute job that spending is for, what data the agent can access as part of that job, or when the authority should automatically expire rather than sitting active until someone remembers to revoke it. That's the same gap OAuth 2.1 leaves in the centralized version of this problem: real coverage of some properties, no coverage of the rest. Closing that gap on a decentralized compute network means pairing the spending primitive that already exists with a scope-and-expiry layer enforced at the program level itself. Nobody's shipped that combination yet specifically for agent compute payments. Building it, even a rough working version tying a scoped, expiring, and task-specific authority to Solana's existing delegation instructions, is a genuinely open architecture problem right now, and exactly the kind of thing worth submitting to a hackathon built around decentralized AI infrastructure. What This Means for Anyone Building on Decentralized Compute A few things follow if you're deploying agents that pay for their own resources: Don't fund an agent's wallet with more than what you're prepared to lose. Until scope and expiry get built on top of the existing delegation primitives, a spending cap is your only real backstop, and it's a blunt one. Use delegation instead of handing over a funded keypair directly. The difference between an agent holding a private key outright and an agent holding a capped, revocable delegate authority is the difference between unlimited exposure and a bounded one. Watch the Subscription Delegation Program specifically if you're running multiple agents or multiple concurrent jobs from one wallet. One delegate per account was never going to scale past a single-agent setup. Conclusion Decentralized compute marketplaces solved the availability problem: cheap, permissionless GPU access without a centralized provider standing in the way. They haven't solved the authority problem for the agents now buying that compute directly. Solana already has half the primitive sitting in its own token program: capped spending and instant revocation. Both are non-custodial and live today. The other half, scope and expiry enforced at the protocol level rather than trusted to an agent's instructions, is still unbuilt. That's a real gap, and it's one this specific hackathon is positioned to close.