Notifications
Clear all
Topic starter
22/06/2026 10:21 am
TL;DR: Internal agents, routines, and workflow systems now help ship code, enrich GTM data, and automate writing, while deterministic harnesses, scoped credentials, and human-verifiable outputs keep those systems usable, according to WorkOS. The lesson for identity teams is that AI capability only scales safely when authority, tooling, and proof are bound to explicit governance constraints.
NHIMG editorial — based on content published by WorkOS: Inside the WorkOS Applied AI Showcase
By the numbers:
- 39 apps shipped to production in a single day during Claude Day.
Questions worth separating out
Q: How should security teams govern AI routines that can change production work?
A: Treat each routine as a separate non-human identity with its own lifecycle, scope, and audit record.
Q: Why do AI workflows need more than standard access reviews?
A: Because the risk is often runtime scope drift, not just excess standing access.
Q: What breaks when AI agents share one automation identity?
A: Accountability breaks first, followed by offboarding and auditability.
Practitioner guidance
- Define separate identities for every AI routine Give each routine its own token, lifecycle, and ownership record so Slack-triggered work, GitHub-triggered work, and API-triggered work are not collapsed into one shared automation identity.
- Require proof before workflow advancement Make test output, smoke evidence, or recorded verification a mandatory input to the next state in any AI-assisted release or content workflow.
- Constrain egress and tool reach Limit AI routines to trusted domains, approved data sources, and explicitly mapped tools so the model cannot expand its effective authority at runtime.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- Specific internal workflow examples for WOW, Horizon, Case, Wallaby, and BlogBot.
- Implementation detail on how the routines are wired into Slack, GitHub, Cloudflare, and internal data systems.
- Concrete lessons from WorkOS' internal experiments on shipping AI across engineering, GTM, and content workflows.
- The company narrative behind why the team chose a model of internal AI capability rather than a standalone service.
👉 Read WorkOS' recap of its Applied AI showcase and internal AI tools →
Applied AI showcase: what it means for AI governance and identity?
Explore further
22/06/2026 11:13 am
AI-native operating models are turning identity controls into workflow controls. WorkOS is showing that AI is not just another workload, because it sits inside the operating loop that creates, changes, and ships company work. That means the effective control plane is no longer limited to login, secrets, or ticketing. The practitioner takeaway is that identity governance now has to describe what an AI routine is allowed to change, not only what it is allowed to reach.
A few things that frame the scale:
- 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, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
A question worth separating out:
Q: How can organisations keep AI-generated changes trustworthy?
A: Require machine-readable proof, not just a successful prompt or a model claim. Test output, smoke results, validation logs, and recorded execution evidence should be part of the workflow itself. That makes the control plane about verifiable outcomes, which is the only defensible way to let AI operate inside release or operations pipelines.
👉 Read our full editorial: Applied AI showcase shows how internal AI systems are changing work
