Your Agent Is Only as Safe as the Token It Borrowed
A security researcher published a write-up this week describing how an estimated 17.3 trillion stored rows across Microsoft datasets were reachable through a single internal analytics service. The root cause wasn't a sophisticated exploit. The service never checked the signature on a login token. That one missing check let him claim an administrator's identity and run queries he had no business running.
Same week, on the other end of the stack, a well-known terminal project reversed its long public position and shipped MCP support — essentially conceding that agent tool interfaces are so hard to compose cleanly that the "right" design keeps moving. And the recurring theme on Hacker News came from three directions at once: always-on agents that keep working while you sleep, conversational agents that quietly widen what they can see, and a widely-shared product that "blatantly ignores user permissions."
None of these are stories about a model going rogue. They're stories about identity that nobody verified.
Agents don't attack. They act with borrowed credentials.
When you give an agent a capability, you're not just giving it a prompt. You're giving it an identity: a token, a key, a service account, a session. And that identity usually comes with more scope, longer life, and thinner auditing than anything a human would get.
Three failure modes show up again and again:
Unverified identity. Someone downstream trusts a token without checking who it really is — the 17-trillion-row story in one sentence. An agent wiring services together inherits every one of those assumptions.
Over-scoped authority. Your support bot needs to read tickets. It ships with write access to everything, because scoping is tedious. Now one bad tool call can rewrite data instead of reading it.
Permanent credentials. Tokens that never expire, keys pasted into env files, service accounts created "temporarily" two years ago. The longer a credential lives, the more chances it has to leak — and the harder it is to know what it touched.
Why cross-border operators feel this first
Cross-border automation is, structurally, a chain of delegated access: a store agent that reads orders, a support agent that reads and replies to messages, a fulfillment agent that updates statuses — each calling tools across vendors and regions. The blast radius compounds:
- Your data lives across jurisdictions, so an over-scoped credential can trip a compliance problem, not just a security one.
- You're often asleep when your customers aren't. An always-on agent acting on a bad credential does its damage at 3 a.m. your time.
- You're running lean. A single agent with admin rights is cheaper to build than four services with narrow scopes — right up until it isn't.
Treat the agent's identity as the real attack surface
The lesson from the token story is boring and durable: verify, scope, expire, log.
- Verify every hop. A token is a claim, not proof. Check the signature and the issuer on every service your agent touches — never "because it's internal."
- Least privilege, by default. Give each agent the smallest scope that does its job, and make widening scope a deliberate, reviewed act. A reader should not be able to write.
- Short-lived, scoped credentials. Prefer tokens that expire in minutes and are minted for one task over keys that live for months. Rotate aggressively.
- A kill switch that actually kills. One switch that revokes the agent's identity everywhere — not five places someone has to remember.
- Log privileged actions as events, not noise. Write down what the agent did, with whose authority, against which resource. When (not if) something goes wrong, the log is the difference between a 20-minute incident and a 20-day one.
The uncomfortable takeaway
We keep asking whether agents are "aligned" and "safe," as if safety were a property of the model. The incidents that actually hurt people this week were all downstream of the model: a token nobody verified, a scope nobody trimmed, a credential nobody rotated.
Your agent is exactly as powerful as the identity you handed it — and exactly as dangerous as the checks you skipped on the way in. Build as if the model is trustworthy and the token is not. That's the boring posture that survives contact with production.
Verify the identity. Trim the scope. Expire the key. Log the act.
Part of a series on running a cross-border store without getting captured by it.
Top comments (0)