The log was accurate. Every proxied request produced an entry with the timestamp, credential reference, endpoint, status code, and duration. Nothing was missing in the technical sense.
But when something unexpected showed up, the first question anyone asked was the one the log could not answer: which agent did this?
In a single-developer setup that question has an obvious answer. There is usually one agent running, one project configured, one reasonable explanation for any given entry. You can work it out from context.
The moment a team starts running multiple agents across multiple workflows, that changes. A billing tool, a reconciliation script, and a new integration being tested alongside established ones all share the same log. STRIPE_KEY used at 14:22 on api.stripe.com โ which one made that call? The log had nothing to say.
That gap is what agent identity closes.
What shipped in v1.1.1
Every agent using AgentSecrets can now carry a name. That name travels with every credential call the agent makes and appears in every log entry it produces.
The entry that used to look like this:
14:22:01 STRIPE_KEY api.stripe.com POST /v1/charges 200 143ms
Now looks like this:
14:22:01 billing-tool issued STRIPE_KEY api.stripe.com POST /v1/charges 200 143ms
One field added, and every entry is fully attributed.
Three levels, because adoption matters
We built the identity system with existing codebases in mind. Anonymous calls continue to work exactly as before, nothing breaks and nothing is required. Identity is something you add when you are ready.
Declared identity is one line:
client = AgentSecrets(agent_id="billing-tool")
The agent asserts a name, the proxy logs it, and there are no tokens, registration steps, or configuration beyond the line itself. For internal tooling and single-developer workflows, this covers everything.
Issued identity is for when the log needs to be trustworthy in a stronger sense. Register the agent, get a signed token, pass it at initialisation:
agentsecrets agent token issue "billing-tool"
# โ agt_ws01hxyz_4kR9mNpQ...
client = AgentSecrets(agent_token="agt_ws01hxyz_4kR9mNpQ...")
The proxy verifies the token cryptographically on every call. A process cannot produce a log entry that says billing-tool without the token. The audit trail is bound to the registration, not to whatever name the process claims.
Finding the gaps
One of the most useful things this enables is discovery, finding the calls that still have no identity attached.
agentsecrets log list --identity anonymous
Every result is a process that has not been updated yet. In a team running multiple agents, this is how you know exactly where your coverage is incomplete. A clean result means every call in the log is attributed.
Token management
A named agent can have multiple tokens, one per environment, one per deployment context. Revoking one does not affect the others.
agentsecrets agent token issue "billing-tool" --label production
agentsecrets agent token issue "billing-tool" --label staging
agentsecrets agent token revoke "billing-tool" agt_01HDEF...
Historical log entries made by a revoked token remain and stay attributed to the agent that made them. Revocation stops future calls without erasing the past.
What this is building toward
Agent identity is the foundation the governance layer builds on. Session binding, policy snapshots, and capability contracts all require a stable identity anchor to attach them to, and now there is one.
The engineering breakdown of how the identity system was designed, including the full three-level model and what each level guarantees, is in the Building AgentSecrets series at engineering.theseventeen.co.
AgentSecrets v1.1.1 is available now.
brew upgrade The-17/tap/agentsecrets
github.com/The-17/agentsecrets ยท agentsecrets.theseventeen.co
Top comments (0)