Verified AI agent identity policy

The control gap

A caller-supplied agent name can be impersonated and must not satisfy a rule intended for a registered production principal.

Replace the example principal with the stable ID created in the Identities screen. The principal secret is not a policy value and should never be pasted into YAML. Require `identity_verified: true`; otherwise an assertion-only request using the same display name may match ordinary agent fields. Test both request types before enforcement.

The identity token is short-lived, but its delegation can expire earlier. Keep tasks and purposes narrow enough for a reviewer to understand. If an agent is disabled or its secret rotates, historical decisions retain the original principal ID and verification state. Create a new policy version when replacing identities instead of editing past evidence.

Registration and authentication are different events. Register the principal with an owner, workload, environment, version, and rotation policy; authenticate each runtime instance with a credential or trusted workload exchange. A display name, user-agent string, or model identifier supplied inside the request is not verified identity.

Exercise substitution attacks before enforcement. Present a valid credential for another agent, reuse a token in the wrong project, change the audience, backdate the delegation, and send an asserted principal beside an authenticated one. The policy input should use only the server-verified subject and retain rejected provenance for investigation.

Rotation must not erase continuity. Issue the replacement secret once, overlap it only for a deliberate migration window, and revoke the predecessor after workloads move. Decisions made under either credential should resolve to the same stable principal while recording the credential generation and runtime instance that authenticated.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "invoke_tool" rather than every operation exposed by the tool.
• Scope the target to production tools that require a cryptographically verified principal and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

Verified AI agent identity policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: verified-agent-identity
match:
  identity_verified: true
  agent_principal: ["agent_release_production"]
  environment: production
decision: allow

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted invoke_tool, including denied requests.
• The exact production tools that require a cryptographically verified principal selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?