When we started handing real tasks to coding agents, we did the obvious safety work first. The agent gets a read-only credential, scoped to one task, that stops working when the claim ends.
Then a colleague asked a question I did not have a good answer to.
The question
If the task context includes attachments, a spec PDF, a screenshot of the bug, a CSV of the failing rows, how does the agent actually fetch them?
The usual answer is a signed URL. The context payload contains a link, the agent GETs it, done.
Here is the part that took me a while to properly absorb: that URL is its own credential. It is a bearer token wearing a URL costume. Which means:
- Revoking the task credential does not revoke it. The read token can be completely dead and the attachment link still works.
- It does not care who presents it. Anything that can read the URL can read the file.
- It leaks the way URLs leak, which is to say constantly. Logs, error reports, a screenshot of a terminal, a model provider request history, a traceback pasted into a group chat.
None of that is exotic. It is the ordinary lifecycle of a string in a distributed system.
Why agents make this sharper
A human opens an attachment in a browser and the URL dies quietly in their history. An agent puts it in a context window, which may be logged, retried, cached, or forwarded to a subagent. The number of places that string comes to rest goes up by an order of magnitude, and most of them are not places you thought about when you designed the expiry.
What to actually do
- Treat attachment URLs as secrets in your logging policy. If you redact tokens from logs, redact these too. They are the same class of thing.
- Give them a shorter life than the session. The agent needs the file for one run, not for the seven days the claim might last.
- Do not log whole context payloads at info level. This is where most accidental exposure actually comes from, not from anything clever.
- Scope them to the resource, not the account. A leaked link that exposes one PDF is an incident. One that exposes a bucket is a very different afternoon.
The documentation point
The thing I have come to care about more than the mechanism is whether the vendor says it out loud. A system can handle this correctly and still leave you guessing about whether revocation covers attachment links, and you will guess wrong in the optimistic direction.
The handoff skill docs for Wagglet state it flatly: attachment URLs returned in context are independent bearer links, keep them private, and revoking the task read credential does not revoke a URL already returned. That sentence saved me an experiment, which is what good documentation is for.
Disclosure: I work with the team that builds Wagglet. The advice above applies to any signed-URL scheme you happen to be using.
If you are designing this layer right now, the question worth writing on the wall is simple: when the credential dies, what is still alive?
Top comments (0)