All posts

Agentic IAM digest / Issue 04

Keep authority
outside the agent.

Agentic IAM digest · October 25–31, 2026. NIST sets out design principles for independent controls, IBM brings agent identity and credential capabilities into general availability, and researchers examine whether an intervention improves the outcome.

Abstract agent nodes follow luminous paths through separate translucent authorization gates.
Identity, bounded authority, and evidence along the action path. AI-generated editorial illustration.

An agent can propose an action, but the systems deciding whether it may proceed need their own authority. This week’s developments make that separation more concrete: distinct identities, credentials issued for a defined task, policy outside the reasoning loop, and evidence that an intervention achieved its purpose.

01 / What changed

Give the controls a boundary of their own

October 27 · NIST proposes ten design tenets for agent IAM

NIST’s new design tenets call for agent identities distinct from human accounts, cryptographically linked delegation with narrowing permissions, short-lived and revocable authorization, and evidence held independently of the agent. They also separate policy enforcement from model reasoning and put deterministic mechanisms at the center of access decisions.

Human review has a defined role: organizations should set escalation thresholds and provide enough context for a decision, while accounting for approval fatigue. A model’s risk assessment can inform an access decision without becoming the authority that grants it.

These are proposed design principles in a NIST blog, intended to guide NCCoE demonstrations and organizational roadmaps. They are not a new mandatory standard or a completed interoperability demonstration. NIST acknowledges that current technology and standards do not yet fulfill every tenet.

For an architecture review, the useful question is concrete: can the agent change the permissions, credentials, or evidence that constrain its next action?

NIST: Design Tenets for Agent Identity Management Systems · October 27, 2026

October 26–27 · IBM connects agent identity with credential control

IBM’s October 26 announcement makes Agent Identity generally available. The company describes an inventory with ownership and lifecycle state, on-behalf-of delegation, task-scoped tokens, contextual authorization, and audit trails connecting people, agents, credentials, and downstream actions. IBM Verify provides identity and governance controls; HashiCorp Vault brokers target-specific credentials for systems that cannot consume delegated tokens directly.

At TechXchange on October 27, IBM also lists Vault 2.2 as generally available. It describes agent-specific accounts, credential renewal, and access denial or session revocation when an agent exceeds approved permissions. Those are vendor capability claims; an evaluation still needs to establish which connected systems enforce the intended boundary.

Availability differs across the portfolio. Orchestrate’s evaluation capabilities are generally available, while its discovery and containment capabilities are in tech preview. Secure Hub is in public preview. The broad announcement should not be read as general availability of every control.

For buyers, follow one task from delegated identity to the credential accepted by the target service. Then withdraw permission and check what the service actually refuses.

IBM Agent Identity availability · October 26, 2026
IBM TechXchange announcement and availability breakdown · October 27, 2026

October 27 · An OAuth draft examines the gaps between grants and actions

Revision 05 of Agent Authorization use cases and gap analysis examines authorization context, delegation chains, and withdrawal of authority across agent workflows. Its cross-organization discussion distinguishes actor history from proof of the restrictions granted at each delegation step.

The draft recognizes existing building blocks, including Rich Authorization Requests, Token Exchange, revocation, and introspection. It identifies remaining questions about relating later approvals to an original task and propagating withdrawal across dependent grants and authorization servers. That is more specific than saying OAuth cannot support agent delegation.

This is an individual Internet-Draft, not an adopted IETF standard or an endorsed protocol. Its value for implementers is a set of interoperability questions: what authority was derived, which restrictions survived, and how does a downstream service learn that permission ended?

Agent Authorization use cases and gap analysis · individual draft 05, dated October 27, 2026

02 / Research signals

A good alarm does not guarantee a useful intervention

October 27 · Restart monitors need evidence about recovery

A preprint by Siddharth Jain and Venkat N. Vedam asks whether a failure prediction justifies restarting an agent. Their mathematical example holds monitor accuracy at 90% yet moves the effect on task success from a five-point loss to a 35-point gain by changing the replacement attempt’s chance of finishing within the remaining budget. That range is analytical, not a measured improvement from a deployed monitor.

The study covers 194 model executions on 19 selected SymPy issues from SWE-bench Verified. An apparent restart gain did not replicate on new task groups tested afterward. A later audit found insufficient statistical support to recommend either action in 103 live comparisons under its chosen rule; that does not establish that continuing was always preferable.

The experiments are limited to selected tasks from one repository, with later interventions using one model and one compact harness. The result supports evaluating the recovery action and its costs alongside detection quality, rather than treating an accurate warning as sufficient evidence for automatic restart.

Monitor Accuracy Isn’t the Answer · preprint v1, submitted October 27, 2026

03 / Context and direction

Where this is heading

Our reading is that the next useful comparison between agent-control systems will concern who can change a decision, where it takes effect, and what evidence survives afterward. An inventory or a policy statement alone leaves those questions unanswered.

1. Separate the ability to request from the ability to authorize

The same agent may need broad knowledge of a workflow and narrow authority to alter it. Keep its proposed action, the approval decision, and the credential issued for execution connected, with a clear owner for each. Test whether changes to the request invalidate the earlier approval.

2. Test withdrawal at the receiving service

A central revoke button is useful only when its effect is understood downstream. Include exchanged credentials, delegated work, retries, and calls already dispatched. Record the delay before new operations are refused and distinguish that from the handling of work already in progress.

3. Judge recovery by the resulting work

Pausing, restarting, resetting context, and escalating to a person are different interventions. Give each a defined purpose, authority boundary, and outcome check. A cleaner error label is useful operationally; it does not by itself show that the business task recovered.

04 / What to watch

Questions for the next deployment review

  • Control ownership: can the agent edit the policy, credential path, or log used to judge its own actions?
  • Delegation: can the receiving service establish the restrictions behind a request, including later approvals and withdrawals?
  • Availability: which controls are generally available, and which require a preview deployment?
  • Recovery evidence: does an intervention improve verified outcomes within its time and cost budget?

Published by AgentAction, which develops controls for agent actions.

Previous issue: October 18–24 · All digests