Carry the person's identity through the call. Do not reconstruct it afterwards. If your agent authenticates as itself and acts for whoever asked, the record at the far end says the agent did it. The link back to a human then lives in a correlation you hope somebody kept. That is the weakest evidence you can hand an auditor, because it rests on a join nobody tested. The stronger shape carries both identities: your agent as the actor, the person as the authority it acts under. Attribution becomes a field in the record. It stops being an investigation.
Related: Does my agent need its own identity, or can it use the user's credentials?, How should I log agent actions so the log is usable as evidence later?
Give it its own, acting on behalf of the user rather than as them. Borrowed credentials make every action indistinguishable from something your user did. That destroys attribution at the moment you need it. It also hands your agent the user's whole authority instead of the slice it needs. A separate identity lets you scope the agent below the person who invoked it. You can revoke it without touching them. You can see its actions in a log as its own. The cost is two identities to carry through every call. That is real work, and it is worth it.
Related: How do I attribute an action an agent took to the person who authorised it?, How do I scope an agent so it can only reach the caller's own resources?
Do not give it one. Give it a short-lived credential something else issues, and let your platform hold the long-lived material. A secret in a prompt is a secret in every log, every trace, and every provider's request payload. In an environment variable it is better, and still lives as long as your process. What you want is your agent presenting an identity and getting a token scoped to the task. Then a leak costs you minutes rather than a rotation. If you cannot do that yet, keep the secret out of anything the model reads.
Related: Does my agent need its own identity, or can it use the user's credentials?, How do I attribute an action an agent took to the person who authorised it?
It breaks attribution unless you carry identity across the hop. Your second agent sees a call from the first. Whoever authorised the work is now two steps away, and reconstructing that chain depends on a correlation nobody tested. Pass the originating authority through each call, so the record at the far end still names your human. Then answer the harder question. Does your second agent get the first one's scope, or its own? Inheriting is easier, and it quietly grants your deepest agent everything the shallowest one had.
Related: How do I attribute an action an agent took to the person who authorised it?, Does my agent need its own identity, or can it use the user's credentials?
Yes. The difference is that nobody authorised the run. A user-invoked agent inherits an authority you can name. A scheduled one acts on a timer, so whose behalf it acts on has no natural answer and your question gets skipped. Give it its own identity and its own scope, sized to the job rather than borrowed from whoever set it up. Record what triggered it. A run with no trigger in your record looks the same as one you started by hand. Unattended runs need your stop control more, not less.
Related: Does my agent need its own identity, or can it use the user's credentials?, How do I keep a human able to intervene in a long-running agent task?