Notifications
Clear all
Topic starter
07/06/2026 8:22 pm
TL;DR: At AWS re:Invent 2025, founders and builders reported that 70-80% of code is now AI-written, Intercom’s AI agent resolves 86% of customer conversations without human involvement, and Claude Code is crossing from assistant to agent, according to WorkOS. The identity problem is no longer access to AI tools, but governance for systems that can act on their own.
NHIMG editorial — based on content published by WorkOS: 10 takeaways from AWS re:Invent 2025
By the numbers:
- Multiple founders told us 70-80% of code at their companies is now written by AI.
- Intercom's AI agent resolves 86% of customer conversations without human involvement.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that can write and deploy code?
A: Security teams should govern AI agents as distinct identities with explicit tool scope, task boundaries, and revocation paths.
Q: Why do AI agents create new identity risks compared with normal automation?
A: AI agents create new identity risks because they can choose their next action at runtime instead of following a fixed script.
Q: What do teams get wrong about AI agent access reviews?
A: Teams often assume an access review can certify an agent the same way they certify a human or a service account.
Practitioner guidance
- Inventory every AI agent as a distinct identity subject Record which repositories, build systems, ticketing tools, and deployment paths each agent can touch.
- Bound agent execution with task-scoped permissions Grant the minimum tool set needed for a single workflow and remove standing access where the task can be completed with ephemeral permissions.
- Place human re-entry points inside the workflow Insert approval or verification steps before commit, before deployment, and before any privilege expansion.
What's in the full article
WorkOS's full article covers the interview detail this post intentionally leaves for the source:
- Direct founder and CTO quotes on how teams moved from experimentation to production AI usage.
- Per-company observations on developer productivity, code generation, and enterprise adoption.
- The broader re:Invent context behind the shift from assistant-style AI to agentic execution.
- The full list of companies and practitioners interviewed at AWS re:Invent 2025.
👉 Read WorkOS's takeaways from AWS re:Invent 2025 on AI agents and enterprise adoption →
AI agent agency and identity controls: what IAM teams need?
Explore further
07/06/2026 10:14 pm
AI agent identity controls are now the governance gap, not the interface layer. The article makes clear that agents are moving from answering questions to performing work inside developer and operations pipelines. That changes the control problem from access to a tool to authority over a sequence of actions. Practitioners should treat each agent as a governed executor with explicit tool scope and revocation paths.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: How should organisations offboard an AI agent when a workflow changes?
A: Organisations should offboard an AI agent by revoking credentials, removing tool bindings, and checking for downstream service accounts or deployment hooks created for the workflow. If the agent can still reach repositories or runtime environments after its job changes, the lifecycle was never fully closed and the identity remains active in practice.
👉 Read our full editorial: AI agent agency is reshaping enterprise identity controls
