By default, nobody checks it by hand. When an AI agent launches a token, its safety rests on three things: the rules written into the launch tool, the locks and vesting set at launch, and the checks a buyer runs. In one study of a popular launchpad, only 0.63% of 655,770 new tokens made it past the first stage.
A note on the legal and regulatory points here: they summarise public sources as of November 2026 and should not be relied on. Rules for AI agents are still being written, and some of what is described here is proposed or coming soon rather than settled. Check the current position, or ask a qualified professional, before acting on it.
Who is responsible for safety when an agent launches a token?
Responsibility is split across four parties, and none of them is a guaranteed safety check. A human-run launch has at least one person who chooses the settings and can be asked about them. An agent-run launch can go from request to live trading with no person reading it.
| Party | What it can do | Where it falls short |
|---|---|---|
| The launch tool’s code | Force a pool lock, minimum vault periods and fee caps on every token | Enforces only what the template requires; defaults can be weak |
| The agent’s developer or operator | Choose the settings and control the wallet | Who answers for an agent’s actions is legally unsettled |
| Lock and vesting contracts | Hold liquidity and allocations for a fixed time | Protect only what is actually put into them |
| The buyer, human or agent | Check the token before buying | Nothing requires a check; at machine speed, many may not run one |
The weak link is the last row. If the tool’s defaults are loose and no one reads them, the token goes live with whatever was chosen.
What protections can be built into an agent-launched token?
The same protections a careful human team uses can be applied automatically at launch: liquidity locks, vesting and reviewed code. The difference is that a machine applies them the same way every time, for better or worse.
Liquidity locks. A liquidity lock puts the trading pool’s funds in a contract that no one can withdraw before a set date. One AI token launcher locks each pool’s liquidity position until the year 2100. One large agent-token platform locks liquidity for ten years once a token leaves its starting phase.
Vesting. Vesting releases tokens gradually, so a creator cannot sell an allocation all at once. On one launcher, a creator’s vault must stay locked for at least seven days. After that, release can be gradual or immediate.
Reviewed code. When every token comes from the same launch template, the contract code is written once and can be reviewed once. That is a real advantage over thousands of one-off contracts. It disappears the moment an agent deploys a custom contract of its own.
These protections work only when they are switched on and set sensibly. A seven-day vault is technically vesting. In practice it gives a buyer very little time.
Defaults matter more for agents than for people. A human team might argue over every setting. Our inference: an agent usually takes whatever the template offers, and it does so for every token it launches. So the launch tool’s defaults become, in effect, the safety policy for thousands of tokens at once.
Why isn’t a locked pool enough?
A pool lock protects only the liquidity inside the pool, while the risk often sits in the supply outside it. If most tokens are held elsewhere, a locked pool can still be drained by selling into it.
On one launcher’s agent skill, extras such as vaults and airdrops can take up to 90% of a token’s supply. That leaves as little as 10% in the locked pool. A token can honestly say “liquidity locked” and still have most of its supply free to sell within days.
An academic study of scam tokens on a high-throughput blockchain shows why the label is not enough. It found three main patterns: abuse of a “freeze authority” that lets a creator block holders from moving tokens, withdrawal of liquidity, and pump-and-dump selling. A pool lock stops only the second. Screening 100,063 new tokens from the first half of 2025, the authors flagged 76,469 as rug pulls.
That study covers all new tokens, not only agent-launched ones. It is the closest large-scale evidence of what happens when launching a token is fast, cheap and unreviewed. Agents make launching faster and cheaper still.
What could go wrong?
The specific risk is safety by default: protections that look complete but cover only part of the token. These are the failure modes to watch.
Settings nobody chose. An agent copies example settings or carries old defaults forward. Our inference, not a measured fact: an agent configured once may keep launching with the same settings long after better ones exist.
Custom contracts. An agent that writes its own token contract skips the reviewed template. That is where hidden functions live: a honeypot (a token you can buy but cannot sell), a hidden mint, or a freeze switch.
Speed. In the launchpad study, the median token that left the starting phase got there in about 4.4 minutes. Of tokens with at least 30 trades, 92.22% had at least one detected dump. No human review process runs at that pace.
Agents buying from agents. When the buyer is also an agent, there may be no person on either side, and no one who pauses because something looks wrong. The same study found that markets dominated by bot-like trading had lower odds of success beyond the middle stages.
No one to answer for it. In October 2026, the CFTC chair asked publicly who is liable if an agent goes rogue, and whether an agent’s developer would become subject to registration. He described these as his own views. The remarks, listed in the CFTC’s index of public statements and remarks, pose the questions. They do not answer them.
The trust takeaway
If an AI launches a token, the safety has to be in the code and in the checks, because there may be no one else. A launch template with sensible defaults is the first line of defence. Your own checks are the second. Before you trust an agent-launched token, check:
- Was it launched through a known launch template, or from a custom contract?
- Is the pool’s liquidity locked, until when, and can you verify the lock on-chain?
- What share of supply sits outside the pool, and what are its lockup and vesting dates?
- Can holders actually sell, and can anyone freeze transfers or mint new tokens?
- Who controls the deployer and admin keys, and can that control change hands?
If any answer is “I can’t tell”, treat that as the answer.
The same list works as a rule for a buying agent. If you run an agent that buys new tokens, tell it to skip any token whose lock, vesting and admin keys it cannot verify on-chain. An agent that refuses to guess is safer than one that buys first and checks later.
Team Finance is built for the lock-and-vest part of this list. It provides token locks, vesting, staking and airdrop tools, and more than 40,000 projects have used it. Where this is going: locks and vesting that an agent can apply as part of its own launch, and a machine-readable lock check that a buying agent could run before it buys. Those agent-facing features are not shipped today.