Topic starter
27/06/2026 1:28 pm
TL;DR: AI agents in production split into delegated, bounded, and autonomous authority models, each with different identity, attestation, and authorization requirements, according to 1Password. The deeper issue is assumption collapse: access review, static least privilege, and human-paced approval loops all break when agent behavior changes at runtime.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Agent identity architectures: Delegated, bounded, and autonomous”.
Key questions
Q: What breaks when AI agents are added to an existing IAM model?
A: The main break is the assumption that access can be reviewed after the fact.
Q: When do autonomous access workflows create more risk than they reduce?
A: They create more risk when the agent has broad privileges, weak review gates, or unclear rollback procedures.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach.
Practitioner guidance
- Classify every agent by authority model Assign delegated, bounded, or autonomous authority before choosing approval, audit, and token issuance patterns.
- Enforce short-lived credentials for agent sessions Issue task-scoped credentials only for the runtime window in which the agent needs them, and revoke them when the task or session ends.
- Separate development and production access Prevent coding agents, workflow agents, and autonomous agents from holding standing production access just because they operate in a development context.
Bottom line: AI agent governance depends on authority model, not just on whether the system is automated. Delegated, bounded, and autonomous agents create different identity and audit requirements.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
27/06/2026 2:50 pm
AI agent identity is a governance classification problem before it is a tooling problem. The article’s delegated, bounded, and autonomous models are not naming variations. They describe different accountability chains, different trust assumptions, and different authorisation lifecycles. Security teams that collapse them into one “agent” category will misapply IAM patterns that only work when behaviour is stable and human-paced.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations treat coding agents and workflow agents the same way?
A: No. Coding agents, browser copilots, workflow assistants, CI/CD runners, and autonomous remediation agents create different trust and runtime profiles. Security teams should separate them by authority model and environment, then apply different issuance, attestation, and revocation rules instead of reusing one generic policy.
👉 Read our full editorial: AI agent identity models expose the limits of traditional IAM