Notifications
Clear all
Topic starter
06/09/2026 6:21 pm
TL;DR: Agent-generated auth code still fails in the same wiring seams that human developers miss, though Ory says its Agent Plugins give coding agents a playbook, local stack, and MCP tool surface for building authentication without an account. The real shift is not convenience, it is whether agentic development can be governed with repeatable guardrails instead of plausible-looking but brittle identity code.
NHIMG editorial — based on content published by Ory: Teach your coding agent Ory Agent Plugins give your agent the skill catalog, the local stack, and the API surface it needs to actually build auth
Questions worth separating out
Q: What breaks when a coding agent generates authentication code without runtime identity context?
A: The most common failures are not syntax errors but stateful integration mistakes: CSRF breaks when the app is not first-party, redirects 404 when routes do not match, server calls fail when request cookies are not forwarded, and SDKs fail if runtime configuration is missing.
Q: Why do AI-assisted auth flows create more risk for IAM teams than ordinary code generation?
A: Because auth is a trust-sensitive runtime system, not a static code pattern.
A: Use a triage sequence that isolates the failure class.
Practitioner guidance
- Validate the auth wiring contract before merge Check first-party cookie scope, redirect route alignment, server-side request forwarding, and runtime SDK configuration on every generated login flow before it is treated as ready.
- Restrict agent access to a governed skill set Limit the agent to approved auth-related skills and MCP tools so it cannot improvise across unrelated identity surfaces or bypass the intended implementation sequence.
- Require structured trace output for agent sessions Keep per-tool traces enabled so reviewers can reconstruct which files, commands, and identity operations the agent touched during auth work.
What's in the full article
Ory's full article covers the operational detail this post intentionally leaves for the source:
- The exact plugin installation and status workflow across Claude Code, Cursor, Gemini CLI, OpenCode, Codex, and other harnesses.
- The full local-stack startup sequence, including the services seeded by the plugin and the port layout used in development.
- The complete MCP tool catalog and tracing model for reviewing what the agent did during an auth build.
- The hand-rolled fallback path for frameworks that do not support the default elements-based flow.
👉 Read Ory's analysis of agent plugins for coding auth flows →
Ory Agent Plugins and agentic auth wiring: what changes for teams?
Explore further
06/09/2026 6:21 pm
Agentic coding creates an auth governance problem, not just a developer-experience problem. Once a coding agent can scaffold login, registration, session, and recovery flows, the security issue is no longer whether the code compiles. The real question is whether the agent is operating inside a controlled identity boundary with observable tool use, predictable runtime context, and reviewable output. That is a governance problem for IAM and NHI teams, not only an application engineering concern.
A few things that frame the scale:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
A question worth separating out:
Q: Should organisations allow coding agents to configure login flows in production directly?
A: No. Coding agents should scaffold and validate against controlled environments, but production login flows need a separate change path, human review, and traceable approval because small wiring mistakes can create user-facing outages or access defects.
👉 Read our full editorial: Ory Agent Plugins expose the auth wiring gap in agentic coding
