SPHR Enterprise Agentic Multi-Purpose Harnesses — Agent Identity & Zero Trust — Part 2

Part 2 of 5 · SPHR Enterprise Agentic Multi-Purpose Harnesses

An autonomous agent that can call tools, move data, and delegate to other agents is a new kind of principal on your network — and treating it like a human user or a shared service account is where zero trust quietly breaks. In the SPHR Enterprise Agentic Multi-Purpose Harnesses, the orchestrator spins up ephemeral subagents on demand, each with its own persona, model tier, and allowed tools. Every one of them needs an identity you can attest, scope, and revoke. This is Part 2 of our series — Part 1 covered the control plane you own. Here we make agent identity concrete: why a shared account fails, how each subagent gets a short-lived attested identity, why there are no static keys anywhere in the agent path, and how every action is authorized on the intersection of what the agent may do and what the human behind it may do.

Agents are non-human identities — and they multiply

Non-human identities already outnumber human ones in most enterprises, and agentic AI is the fastest-growing class of them. A harness makes that concrete: a single conversation can spin up many subagents, each acting for seconds and then torn down. A shared service account collapses all of those actors into one credential — you cannot tell which agent did what, you cannot scope permissions to a single task, and the blast radius of that one credential is everything all of them are allowed to touch. Borrowing a human's credentials is worse: every action is misattributed to a person, and the person's full access becomes the agent's. The design requirement follows directly — identity must be per-agent, scoped, verifiable at the moment of action, and revocable on its own. We made the broader case for treating agents as first-class identities in zero-trust identity for AI agents; a harness operationalizes it.

A short-lived, attested identity per subagent

When the orchestrator spins up a subagent, that subagent is issued an attested, short-lived credential — minted at spin-up and expiring at teardown, so there is no long-lived identity sitting around to be stolen or reused. AGT supplies a per-agent cryptographic identity using decentralized identifiers signed with Ed25519 (DID/Ed25519), and a managed agent identity broker handles the lifecycle: issuance, adaptive access, and per-agent revocation. Revocation is the property most platforms miss. Because each subagent has its own identity, you can revoke exactly one misbehaving agent without tearing down the conversation or the other agents around it. Short-lived, attested, and individually revocable is the opposite of a shared key that lives in an environment variable forever.

No static keys — token exchange, not injected credentials

A harness holds no static keys in the agent path. The control-plane registries store only references to credentials; the actual secrets live in a separate secrets vault and resolve at call time. When a subagent needs to reach a model or a tool, the AI gateway performs a token exchange to obtain a short-lived, narrowly scoped token for that specific call — it does not inject a long-lived API key into the agent. That single move answers one of the sharpest agent-security failure modes: agents that carry baked-in credentials leak them, and a leaked static key is a standing breach. "AI agents without static credentials" is not a slogan here; it is the mechanic — reference-only registries, a vault for the real secret, and token exchange at the boundary.

Per-action authorization: user rights ∩ agent rights

Identity answers "who is acting." Authorization answers "may this action happen." A harness checks the second on every tool call, not once at the start. The rule is an intersection: an action is allowed only if the agent is permitted to do it AND the requesting member is permitted to do it. Neither alone is enough — a powerful agent must not exceed the rights of the human it acts for, and a privileged human must not get an agent to do something the agent's scope forbids. AGT's policy engine — a policy decision point behind an enforcement point — evaluates that intersection deterministically before the action executes, together with a freshness gate and cost caps. This is the direct answer to OWASP ASI03, agent identity and privilege abuse, which we map alongside the rest of the list in the OWASP Agentic Top 10 checklist.

Delegation carries the human principal end-to-end

Multi-agent work moves: a planner hands a subtask to a specialist, which calls a tool. If identity resets at each hop, the trail dies at the first handoff. In a harness, the human principal is propagated end-to-end, so the record reads as a chain — which member initiated the work, which agent acted, and which agents it delegated to — rather than a series of anonymous requests. Delegation narrows authority: a sub-agent receives a subset of the caller's scope, never more. This is "agent delegation authorization" done so that revoking one link, or answering "who authorized this, across how many hops?", is always possible. And because the identity and the authorization decision are captured at the action layer, the answer is a byproduct of enforcement — the subject of Part 3.

An agent-identity readiness checklist

Before an autonomous agent acts on a real system, confirm all five. If you cannot, you have an actor you cannot account for:

• Per-agent identity. Does every subagent get its own attested identity at spin-up — not a shared service account or a human's credentials?
• Short-lived and revocable. Does that identity expire at teardown, and can you revoke a single agent without disrupting the rest?
• No static keys. Are credentials reference-only in the control plane, resolved from a vault via token exchange at call time?
• Intersection authorization. Is every action checked against both agent rights and the requesting member's rights, before it executes?
• End-to-end principal. Is the human principal carried across every delegation hop, so the chain of who-authorized-whom is always reconstructable?

Continue the series

This is Part 2 of a five-part series on the SPHR Enterprise Agentic Multi-Purpose Harnesses:

• Part 1 — The control plane you own
• Part 2 — Agent identity and zero trust (you are here)
• Part 3 — Governance at runtime: a deterministic policy kernel and tamper-evident audit
• Part 4 — The OWASP Agentic Top 10, controlled: ASI01–ASI10 answered with concrete controls
• Part 5 — Multi-tenant knowledge, memory, and cost: isolation and FinOps at the action layer

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We give every agent in a harness a first-class identity your security team can defend: attested and short-lived, individually revocable, with no static keys, and every action authorized on the intersection of agent and user rights. As an Anthropic partner working model-agnostic and multi-cloud, we design the identity layer to outlast any single framework or model you adopt. If you cannot answer "who did the agent act as, and was it allowed to?", let's fix your agent identity story.

Frequently asked questions

Why can't AI agents share a service account?

A shared service account collapses many agents into one identity, so you cannot tell which agent acted, you cannot scope permissions to a single task, and the blast radius of that one credential is everything all the agents can touch. In a harness a single conversation may spin up many short-lived subagents, so each one gets its own attested identity instead — the only way to make actions attributable and least-privilege enforceable.

What makes an agent identity attested and short-lived?

Each subagent is issued a cryptographic identity at spin-up that expires at teardown, so there is no long-lived credential to steal or reuse. AGT supplies a per-agent decentralized identifier signed with Ed25519 (DID/Ed25519), and a managed agent identity broker handles issuance, adaptive access, and per-agent revocation — so you can revoke exactly one misbehaving agent without disrupting the others.

How do AI agents work without static credentials?

The control-plane registries hold only references to credentials; the real secrets live in a separate vault and resolve at call time. When a subagent reaches a model or tool, the AI gateway performs a token exchange to obtain a short-lived, narrowly scoped token for that specific call rather than injecting a long-lived API key. No static key ever sits in the agent path, so there is nothing durable to leak.

What is per-action authorization for AI agents?

Every tool call is authorized on the intersection of what the agent may do AND what the requesting member may do — checked before the action executes, not once at startup. A powerful agent cannot exceed the rights of the human it acts for, and a privileged human cannot push an agent past its scope. A deterministic policy engine evaluates that intersection with a freshness gate and cost caps.

How is zero trust for agents different from zero trust for users?

The principle is identical — never trust, always verify — but agents change the shape of the problem. They are non-human identities that spin up and retire in seconds, delegate to other agents, and act at machine speed. So a harness verifies identity and re-checks authorization before every action rather than once at login, propagates the human principal across every delegation hop, and narrows authority as work is delegated rather than widening it.

This series describes the pattern-level architecture of the SPHR Enterprise Agentic Multi-Purpose Harnesses, built on public frameworks — Microsoft's Agent Framework (MAF) and Agent Governance Toolkit (AGT), the Model Context Protocol (MCP), and DID/Ed25519 identity. Implementation details are generalized.