execute transport as any other T3N contract. The only difference is the script_name starts with z:<tid>:.
Agents authenticate as themselves, not as tenants. Like every T3N session, an agent reads its own DID back from the authenticated session — there’s nothing tenant-specific to set.
1. Set up the agent’s identity
An agent is a separate authenticated session with its own key — it is not the tenant and not the user. Build it the same way you builtt3n in Quickstart, but with its own credential:
2. Authorize the contract’s egress (as the user)
Before any function that makes an outbound HTTP call can run, the user (data owner) must authorize it. A tenant contract’s allowed hosts are resolved per-call from the user’s authorization grant — not from the contract. In this walkthrough you’re standing in for the user yourself, so build a third session —userClient — with its own credential, exactly like t3n and agentClient above:
agent-auth-update scoping the agent to your contract, its functions, and the hosts it may reach:
agentDid to the user’s own DID (a self-grant) instead of building a separate agentClient. Without a matching grant the contract still runs, but any outbound call is denied with host/http.egress_denied. See Outbound HTTP is authorized by the user, not the contract.