Notifications
Clear all
Topic starter
08/06/2026 4:50 pm
TL;DR: AI agents combine planning, tool use, and persistent access, which makes identity, instruction design, authentication, and safety controls inseparable from functionality, according to WorkOS. The real governance issue is that these systems can act on behalf of users or products while extending trust across tools, sessions, and workflows.
NHIMG editorial — based on content published by WorkOS: How to build AI agents
Questions worth separating out
Q: How should security teams govern AI agents that can call external tools?
A: Treat each agent as a governed non-human identity with a defined owner, purpose, and tool boundary.
Q: Why do AI agents create new access risk for IAM teams?
A: AI agents can combine delegated access with runtime decision-making, which means their authority can expand across multiple steps and tools.
Q: What do organisations get wrong about agent authentication and tokens?
A: They often focus on proving the agent is authenticated and overlook how much it is authorised to do once it is inside a system.
Practitioner guidance
- Classify each agent as a non-human identity Assign an explicit owner, purpose, and scope to every agent before it reaches production.
- Replace broad service access with scoped delegated access Use short-lived tokens for user-delegated tasks and scoped API keys for product-level automation.
- Treat tool definition as an entitlement review Review every tool name, schema, and description with security and IAM teams before release.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Model selection trade-offs for agent behaviour, cost, and edge-case reliability
- Implementation patterns for LangChain and CrewAI style orchestration
- Concrete authentication examples for API keys, OAuth, and service accounts
- Safety and testing techniques for prompt injection, tool misuse, and failed execution
👉 Read WorkOS's guide on building AI agents, tools, authentication, and safety →
AI agent orchestration and access control: what teams must design?
Explore further
08/06/2026 6:41 pm
Identity boundaries are now part of agent design, not a later governance layer. Once an AI agent can call APIs, read databases, or trigger actions, the security model becomes inseparable from the product model. That means access scope, token lifetime, and tool eligibility must be defined as part of the agent architecture, not bolted on after launch. Practitioners should treat every agent as a governed non-human identity with a measurable blast radius.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do you reduce the chance of an AI agent taking unsafe actions?
A: Use layered controls rather than a single approval step. Filter hostile input before the model runs, validate outputs before any side effect, and reserve human approval for high-impact actions such as spending, deleting, or policy changes. That combination reduces both prompt-injection risk and accidental tool misuse.
👉 Read our full editorial: AI agents need identity, tool, and safety controls to work
