--- title: "Which Person Was Your AI Agent Working For? · Highflame" description: "Your logs say which agent ran the deploy. They rarely say which person it was working for, who proved that, or whether that person still works for you." doc_version: "0.1.0" last_updated: "2026-11-03T03:27:42.789Z" canonical: "https://www.highflame.com/blog/agent-identity-accountable-human" --- [← All articles](/blog.md) # Which Person Was Your AI Agent Working For? Nov 02, 202610 min read Sharath Rajasekar ![Which Person Was Your AI Agent Working For?](/blog/agent-identity-accountable-human/hero.webp) At 2:14 a.m., a test agent pushes a build to production. By 2:20, your incident lead has the log line: `test-agent-7` called the deploy tool with a valid token. The questions that decide what happens next are all about a person. Which person was the agent working for? Did anyone prove that, or did the agent just say so? Does that person still work here? If the log can’t answer them, your incident lead spends the rest of the night reconstructing who the agent acted for from Slack threads and `git blame`. **Your identity provider already knows most of the answers.** Teams now register agents in Okta for AI Agents, Microsoft Entra Agent ID, and AWS Bedrock AgentCore, each with an owner and a lifecycle. Then an agent security product asks you to “create an agent account” in its console, with a new client secret and no link back to the people the agent works for. The agent now exists twice, and the system that knows who owns it is not the system that logged what it did. ## **Three patterns for agent identity** Your identity provider registers agents. Enforcing what they do falls to an agent security vendor, and vendors tend to follow one of three patterns. You can tell which one you have by what the 2 a.m. log can answer. ### **The agent as an account** The agent gets its own principal and client secret, and every call is logged under its name. **The person the agent was working for is not in the log.** If your agent identity solution is built this way, it misses: - **Who the agent acted for:** No person is on the token, so a policy cannot require that the person behind a production deploy is on the release team. - **The relationship to its users:** The agent has an accountable owner, usually an admin. What is never recorded is which developer each run served, so disabling a departing developer cannot stop runs on their behalf. ### **The agent as a delegate** The agent exchanges its credential for a token that names a user, and the log finally shows a person. **The question is how that name got there.** Check whether the implementation closes these gaps: - **Proof of the person:** If the exchange accepts a user ID or email supplied by the caller without validating that the caller has authority to act for that user within the requested scope, then whoever holds the agent’s credentials can act for that user. - **The person after the first hop:** If each exchange makes the delegating agent the new subject, the person drops out when work moves to a sub-agent. - **Approvals per agent:** If an approval is tied to the person and nothing else in it names the agent that asked, one approval can cover every agent working for that person. ### **The agent as a link in an accountable chain** Your identity provider proves the person, each agent authenticates with its own credentials, and the person stays the subject at every hop. The log shows the developer the work was done for, the coding agent that handed it on, and the test agent that ran the deploy, and **the developer’s name came from Okta rather than from the agent.** Highflame follows the third pattern. The rest of this post shows how. ## **The agent doesn’t get to say who it works for** **If the record takes the agent’s word for which user it acts for, the record is only as honest as the agent and anyone who has stolen its credentials.** Highflame marks a token as acting for a person only when that person actually authenticated: - **Okta:** Okta’s Cross App Access issues an identity assertion (an ID-JAG) naming both the person and the agent. The agent redeems it, and the resulting token carries both. - **Microsoft Entra:** An Entra ID token for the person is accepted only from the application it was issued to. A gateway or another app that happens to hold the token cannot redeem it. - **Interactive sign-in:** A person who signs in to an MCP client through the standard authorization flow is recorded as that person. Neither the caller nor a delegating agent can set or upgrade that marker. If no person authenticated, the token says so, and policy treats the call that way. The agent’s side of the exchange is proven too. An agent signs its request with a private key it holds, and Highflame keeps only the public key, so there is no shared secret to copy. When key binding is enabled and enforced by the receiving service, stealing the token alone is insufficient to use it. Policy can also limit who an agent acts for. A policy on the agent can refuse any chain that doesn’t start with an authenticated person, so the agent cannot mint a token for itself or act for another workload. A person’s token can also name the agents allowed to act for that person. ## **The person has to survive every hop** Agents hand work to other agents. In this flow, each handoff uses a token exchange. Some implementations make the delegating agent the new subject at every exchange. At the second hop the coding agent becomes the party being acted for, and the developer is gone from the record. Recording only the current actor does not lose the person. Replacing the subject does. One task, two hops, two ways to write it down developer → coding agent → test agent → deploy tool **Top:** each exchange makes the delegating agent the new subject, so the second hop replaces the person with the coding agent. **Bottom:** the person stays as the subject through every hop, and only the acting agent changes. [Highflame ZeroID](/blog/introducing-zeroid-open-source-identity-for-autonomous-agents.md) issues tokens that follow [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) delegation. **The person stays as the token’s subject (`sub`) at every hop.** The agent acting right now is the outermost actor (`act`), with earlier agents nested inside it as history. Policy and approvals look at the person and the current agent. Earlier agents stay in the audit trail, and they are never the reason a call is allowed. Here is the token the test agent presented to the deploy tool, decoded under each pattern. The 2 a.m. deploy token, decoded abridged · values are illustrative After hop 1 After hop 2 Subject replaced at each exchange ``` { "iss": "https://agents.example.com", "sub": "agent:coding-agent",the person is gone "act": { "sub": "agent:test-agent-7"acting now }, "aud": "deploy-tool", "exp": 1793680440} ``` Highflame, RFC 8693 chain ``` { "iss": "https://auth.highflame.ai", "sub": "user_8c41",still the developer "principal_type": "user", "user_idp_iss": "https://acme.okta.com", "user_idp_sub": "00u1dev42", "act": { "sub": "spiffe://highflame.ai/acme/prod/agent/test-agent-7",acting now "identity_type": "agent", "act": { "sub": "spiffe://highflame.ai/acme/prod/agent/coding-agent"history only } }, "aud": ["deploy-tool"], "exp": 1793680440} ``` **Subject replaced:** the agent names the person, and the second exchange makes the delegating coding agent the new subject. **Highflame:** the person comes from Okta and stays the subject; each hop adds a layer to `act`, and only the outermost one is acting. So a policy on the deploy tool can require that the call’s subject is a verified member of the release team, however many agents the work passed through. That establishes who the chain acts for. Whether this particular deploy needed a person’s sign-off is a separate rule, and approvals cover it. Each hop can only narrow what the chain may do. The new token carries only the scopes that the request, the incoming token, and the agent’s policy all allow, so limits applied upstream carry down the chain. An agent’s policy also caps what it may hold on a person’s behalf separately from its own authority, and a policy can cap how deep a chain may grow. Highflame links every exchanged token to the Highflame-issued token it came from, and an exchanged token never outlives that parent. Revoking a Highflame token revokes every token exchanged from it. The original Okta or Entra token stays under your identity provider’s control; Highflame tracks the tokens it issued. ## **Register agents in your directory or ours** **Wherever an agent is registered, it has a named owner, and when a person is behind a run, that person is proven.** If your agents already live in Okta, Entra, or AgentCore, keep them there, and Highflame federates the identity they already have: - **No client secret from us:** Workloads prove who they are with credentials their platform already issues, such as JWTs from AWS STS `GetWebIdentityToken` (IAM outbound identity federation), Kubernetes service account tokens, SPIFFE JWT-SVIDs, or GitHub Actions OIDC tokens. There is no long-lived Highflame secret to store or rotate. - **The caller can’t pick the tenant:** Which organization a token belongs to comes from an issuer your organization registered and verified, plus a binding to one specific agent. It never comes from a field in the request. - **No binding means no token:** An agent in your directory that nobody adopted in Highflame gets no token from us, so it cannot reach anything Highflame protects. If your agents aren’t in an identity provider yet, register them in Highflame’s agent registry. Registration requires a named owner from your organization, and the agent’s tokens carry the same delegation chain as a federated agent’s. ## **Sensitive calls need a per-agent sign-off** Nightly jobs and pipelines often have no person behind any single run. When the only control is the agent’s standing policy, a sensitive call goes through without anyone signing off on that call or on that agent’s use of the tool. With Highflame’s agent identity policy in place, that call is neither allowed silently nor blocked outright. **Someone has to put their name on it.** For a one-off, that is an approval for that call from an eligible member of your organization, and only your organization can give it; Highflame staff cannot approve on your behalf. For a job that runs every night, it is a standing grant attached to that one agent. A grant stands in for an approval only where your policy says it can, so a payment that needs two people still needs two people. Approvals bind to the agent that asked. Two agents acting for the same person never share one, so an approval given to the test agent cannot be reused by the coding agent that delegated to it. ## **Offboarding shows which pattern you have** Disable a departing developer in your identity provider, then look at the agents that worked for them. If those agents are owned by an admin account and nothing recorded which runs served the developer, nothing about them changes. What happens to a person's agents when the person leaves identity provider → SCIM → agents **Linked to the person:** deactivation in the identity provider stops every agent they own. **Owned by an admin account:** nothing recorded which runs served the developer, so their departure changes nothing. In Highflame, **when your identity provider deactivates a person over SCIM, every agent they own is deactivated with them.** Highflame also revokes every token those agents hold and every token delegated from them, and Highflame’s enforcement points refuse revoked tokens within seconds of Highflame receiving the deactivation. After revocation reaches the enforcement points, the run’s next protected call is rejected. Shared agents are different. An agent owned by someone else keeps running when one of its users leaves. It keeps that user’s authority until the tokens it already holds for them expire, and no new ones are issued, because the person can no longer sign in to the identity provider that proves them. Roles have a similar boundary. Your identity provider’s group claims never grant a Highflame role directly. Roles and project access come from groups you sync over SCIM and map on purpose, so a change to the claims your identity provider sends cannot widen what a person or their agents can do. ## **The protocols are open standards** **The identity and federation protocols are open standards, and Highflame adds the enforcement described above.** - [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) token exchange carries the person and the chain of agents. - Okta’s Cross App Access and OpenID Connect ID tokens prove who the person is. - OIDC workload federation lets AWS, Kubernetes, SPIFFE, and GitHub credentials stand in for client secrets. - SCIM carries people, groups, and deactivations from your identity provider. - OpenID CIBA delivers an approval request to the person who has to approve it. The service that issues these tokens, [ZeroID](/blog/introducing-zeroid-open-source-identity-for-autonomous-agents.md), is open source, so you can read exactly how a token is built. Any verifier that understands RFC 8693 can read a Highflame token, and your auditors can decode one with the tools they already use. ## **Questions to ask an agent security vendor** Put these to any agent security vendor, including us. Question What a weak answer sounds like What to look for Where does the agent’s identity live? In our console, with no link to the people it works for In your identity provider or the vendor’s registry, with a named owner either way and no vendor secret for federated agents Which organization does a token belong to? Whatever the request says An issuer your organization registered and verified Who proves which person the agent acts for? The agent passes a user ID or email, and the exchange takes it The identity provider, through an ID-JAG, an ID token, or a sign-in Does the person survive a second hop? The delegating agent becomes the new subject The person stays as the subject, and earlier agents are history only Can a sub-agent end up with more authority than the agent that delegated to it? The sub-agent gets its default permissions without checking the incoming token’s limits Scope is the intersection of the request, the incoming token, and the sub-agent’s policy at every hop Who signs off on a sensitive call with no person behind it? Nobody; standing policy decides A recorded approval or a standing grant, tied to one agent Who does an approval apply to? The person, with nothing tying it to one agent The single agent that asked What happens when a user leaves? Nothing changes for agents that served them Their owned agents are deactivated and their tokens revoked; shared agents lose that user’s authority when existing tokens expire Can identity provider claims grant roles? Group claims map straight to roles Roles come only from groups you sync and map Your agents will hand more work to each other every quarter. **Every one of those handoffs should still lead back to a person your identity provider proved, or to someone who signed off by name.** If you want to see that against your own Okta or Entra tenant, [talk to us](/contact.md). ## Frequently asked questions What is the difference between an agent account and agent identity? An agent account logs an agent's actions under its own name. Agent identity, as security teams need it, also records which person the agent is acting for and how the identity provider proved that person. How does Highflame work with Okta for AI Agents and Microsoft Entra Agent ID? Highflame federates agents already registered in Okta, Entra, or AWS Bedrock AgentCore, so they need no Highflame client secret. Agents can also be registered in Highflame's own registry with a named owner. Either way, the person an agent acts for is proven by the identity provider and carried through every delegation hop. What happens to an agent when the person who owns it leaves? When your identity provider deactivates the person over SCIM, Highflame deactivates the agents they own and revokes the tokens those agents hold. Shared agents owned by someone else keep running, and they keep that person's authority only until the tokens they already hold for that person expire. Sharath Rajasekar Engineering and research on agent identity, runtime policy, and securing autonomous AI at Highflame. ▸ Continue reading - [ ![AI Agent Containment Is an Authorization Problem](/blog/ai-agent-containment-is-an-authorization-problem/hero.webp) SecuritySep 15, 2026 #### AI Agent Containment Is an Authorization Problem ](/blog/ai-agent-containment-is-an-authorization-problem.md) - [ ![Why an AI Gateway Alone Can't Secure Your AI Agents](/blog/why-an-ai-gateway-cant-secure-ai-agents/hero.webp) SecurityAug 27, 2026 #### Why an AI Gateway Alone Can't Secure Your AI Agents ](/blog/why-an-ai-gateway-cant-secure-ai-agents.md) - [ ![AI Runtime Security: How to Protect Agents and GenAI Apps at Request Time](/blog/ai-runtime-security-how-to-protect-your-genai-stack-from-real-world-threats/hero.jpg) SecurityJul 23, 2026 #### AI Runtime Security: How to Protect Agents and GenAI Apps at Request Time ](/blog/ai-runtime-security-how-to-protect-your-genai-stack-from-real-world-threats.md) ## Start securing your agents today. [Book a demo](/contact.md) ## Sitemap Full site map: [/sitemap.md](https://www.highflame.com/sitemap.md). Machine index: [/sitemap-index.xml](https://www.highflame.com/sitemap-index.xml).