agent identity: how to tell agents apart in logs

agent identity: how to tell agents apart in logs

TL;DR

Give every agent instance a unique ID and stamp it on every log line and tool call. When five agents share one service account, the logs are soup; with per-instance IDs you can answer "which agent did this" in seconds. Identity is what makes every other security control attributable.

agent identity: how to tell agents apart in logs

Use this when

• Multiple agents run under one service account and you cannot tell them apart
• You are investigating an incident and need to isolate one agent's actions
• A customer asks which agent touched their data
• You are setting up logging for a new agent fleet

Not for this skill when

• You run exactly one agent (still do it, but the urgency is lower)
• The problem is authenticating the agent to external systems (that is credential scoping)
• You need to prove an agent's actions to a third party (that needs signed audit trails, a bigger topic)

Steps

1. Mint a unique ID per agent instance.

Combine a stable agent name, a short instance token, and the session ID: something like deployer-a3f9-session-8812. The name tells you what it is, the instance tells you which copy, the session tells you which run.

Expected: no two running agents share an ID, and the ID is human-readable enough to grep.

2. Attach the ID to every tool call and log line.

The agent framework should inject the ID automatically: API calls, file operations, shell commands, database queries, all of it. If the ID is opt-in, someone will forget it exactly when it matters.

grep "agent_id=deployer-a3f9" /var/log/agent/actions.log | tail -20

Expected: every line for that agent's actions, newest last, with no other agent's lines mixed in.

3. Give each agent its own service account.

One service account per agent, or at minimum per agent role. Shared credentials erase identity at the exact layer where external systems log it. The account name should match the agent ID scheme.

Expected: cloud and SaaS audit logs show the agent's own account, not a shared one.

4. Record the human owner and the approver.

Every agent run should log who launched it and who approved its plan, if approval was required. Agents act, but humans are accountable, and the log should show both.

Expected: for any action, you can answer "which agent, launched by whom, approved by whom" from the logs alone.

5. Keep a registry mapping IDs to owners and scopes.

A simple table: agent ID, owner team, what it is allowed to touch, when it was created. When an alert fires on an unfamiliar ID, the registry is the first place you look.

Expected: a registry where every active ID resolves to an owner and a scope description.

6. Retire IDs cleanly.

When an agent is decommissioned, revoke its service account, remove it from the registry, and keep the historical logs. Stale IDs that still work are a quiet backdoor.

Expected: a retired agent's credentials fail, and its past actions remain queryable.

Variant: track which agent did what

That is steps 1 and 2: unique IDs, stamped everywhere. If your framework does not support it natively, wrap the tool layer and inject the ID there.

Variant: agent attribution in audit logs

Attribution needs the ID to survive across system boundaries: pass it as a header, a query comment, or a structured log field so downstream systems record it too.

Variant: multiple agents one account how to separate

Stop sharing the account (step 3). Until you can, at least separate by session ID in your own logs, and treat the shared account as a known gap in the audit trail.

Variant: log correlation ID for agents

The session ID is your correlation ID. Propagate it through every downstream call so one grep reconstructs the whole story across services.

Why this happens

Agent frameworks optimize for getting work done, and identity feels like overhead until the first incident. Then "the agent did it" is not an answer anyone accepts: which agent, running whose task, approved by whom. Teams discover the gap at 2am during an incident review, which is the worst time to retrofit identity.

Edge cases and pitfalls

• Sub-agents spawned mid-task: child agents must inherit a derived ID (parent ID plus a suffix), not mint unrelated ones, or the trail breaks at the handoff.
• IDs in prompts get hallucinated: never let the agent report its own ID from memory. The framework injects it; the agent just carries it.
• Log volume explodes: stamp the ID as a structured field, not a prose sentence. Structured fields compress and index; sentences do not.
• External systems drop your headers: log the mapping at your boundary (your request ID to their request ID) so you can still join the trails later.
• Humans and agents share tooling: prefix agent IDs distinctly (for example agent-) so a glance at any log line tells you whether a human or an agent acted.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hI3UIJi0O5PN-3sdNJYMOw