Ory Agent Plugins expose the auth wiring gap in agentic coding

At a glance

What this is: Ory Agent Plugins package auth skills, local infrastructure, and tool access so coding agents can scaffold login flows with less guesswork, while exposing how often identity failures come from wiring, not APIs.

Why it matters: IAM and identity teams should care because agent-generated auth code increases the speed of both delivery and defect propagation, making session, redirect, and cookie governance part of the development control plane.

👉 Read Ory's analysis of agent plugins for coding auth flows

Context

Agentic coding changes the identity problem from a human developer clicking through auth setup to a software actor composing login flows, routes, cookies, and session handling at runtime. In that setting, the failure modes are often not missing features but incorrect assumptions about redirect targets, request context, and browser versus server execution.

Ory's article is about that exact gap: coding agents can produce plausible authentication code that still breaks because the integration logic is wrong. For IAM teams, the deeper issue is that agent-assisted development now sits inside the same governance boundary as NHI and workload identity, where tool access, runtime context, and traceability all matter.

The starting position here is typical of modern agentic development: enough scaffolding to be dangerous, but not enough identity context to be correct without guardrails. That makes the post relevant beyond one vendor's stack because the underlying control problem is portable across agentic AI, NHI, and human-built application flows.

Key questions

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. Generated auth code needs runtime verification, not just compilation.

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 coding agent can generate plausible login flows that inherit session, cookie, and redirect errors at machine speed, which means identity teams must govern the implementation boundary as well as the source code.

Q: How can security teams tell whether a generated auth failure is in the app or in the identity service?

A: Use a triage sequence that isolates the failure class. If a direct flow API call works but the page fails, the problem is usually the app. If the flow API call fails, the issue is more likely the identity service or tunnel configuration.

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.

Technical breakdown

Why agent-generated auth code fails at the wiring layer

Auth integrations fail most often at the seam between identity provider behavior and application runtime. Common breakpoints include CSRF protection that expects first-party cookies, redirect routes that do not match the app, server-side calls that lose request cookies, and SDKs that are initialised with the wrong environment variable at runtime. A coding agent can emit code that compiles and still miss these stateful requirements because they are not obvious from static API usage.

Practical implication: treat auth scaffolding as a runtime wiring problem and verify cookie flow, redirect targets, and server-side request context before calling the build complete.

How an MCP-backed skill catalog changes agent behaviour

The plugin pairs a skill catalog with a local stack and an MCP surface, which means the agent is not just writing code but also querying tools, reading service state, and following a prescribed sequence. MCP here matters because it gives the agent access to structured operational knowledge and actions rather than relying only on pretraining. That reduces improvisation, but it also concentrates control in the tool surface and the skill definitions the agent is allowed to invoke.

Practical implication: govern the tool catalog as part of the identity boundary, because the agent's effective privileges are defined by its available skills and MCP tools.

What local tracing reveals about agentic identity operations

Local tracing turns agent activity into an auditable event stream, with one span per tool call and enough metadata to reconstruct what happened without exposing full secrets or payloads. That matters because agentic work often crosses file, shell, and network boundaries in a single session, which makes transcript review a weak control. Structured tracing is closer to a security control than a developer convenience because it creates evidence of access, sequence, and intent boundaries.

Practical implication: require traceable agent sessions when coding agents can alter auth code, so identity and security teams can review actions after the fact.

NHI Mgmt Group analysis

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.

Identity flows are now shaped by software actors that can misconfigure trust just as quickly as they can generate code. The article shows how easily a coding agent can produce plausible authentication logic that still fails on redirect alignment, cookie forwarding, or server versus browser session handling. That pattern maps to NHI governance because the agent is effectively an identity-bearing workflow participant whose output can inherit privilege mistakes at machine speed. Practitioners should read this as a call to govern the agent's operating model, not merely its prompts.

Named concept: auth wiring drift. This is the gap between seemingly correct generated authentication code and the runtime assumptions that make identity work in practice. It matters because each generated edit can silently move the app away from the intended flow contract, especially when the agent is allowed to improvise across framework boundaries. The practitioner conclusion is simple: inspect the wiring contract, not just the code diff.

Local stacks and test harnesses do not remove identity risk, they relocate it. Running Ory locally without an account lowers setup friction, but it also means the agent can work inside a self-contained environment where errors are easy to miss until production integration. That is a familiar NHI pattern: convenience often masks whether the control plane is actually enforcing the intended boundary. The implication is that teams need the same review discipline for agent-created auth scaffolding that they already apply to machine identities.

Agentic development will push IAM teams toward evidence-based controls. The strongest signal in this article is the move from ad hoc generation to a playbook plus trace model. That direction aligns with broader identity governance because the security question becomes whether every privileged tool call, route change, and session assumption can be reconstructed. Practitioners should treat agentic coding as part of identity lifecycle governance for software actors.

From our research:

• 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.
• That governance gap matters here because agentic coding is expanding the number of machine-driven identity operations that need review, traceability, and lifecycle control.

What this signals

Auth wiring drift: when coding agents generate identity flows, the programme risk is not just bad code but silently incorrect trust assumptions that survive compile-time checks. Teams that already struggle with workload identity governance should expect the same pattern to appear in agent-built login paths, especially where server-side session handling and redirect contracts are involved.

The identity control lesson is broader than one product stack: software actors are now participating in implementation decisions that used to be reserved for humans. That means IAM and application security leaders need observable artefacts, not just code reviews, if they want to detect when generated auth logic has drifted away from the intended control boundary.

For practitioners

• 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.
• Separate local scaffolding from production trust decisions Use local stacks for development convenience, but require a distinct review path before any generated auth logic is connected to real identity providers or production session state.

Key takeaways

• Coding agents can accelerate authentication delivery while also accelerating wiring mistakes that only appear at runtime.
• The key control question is whether generated identity flows preserve cookie scope, redirect integrity, and server-side request context.
• Agentic development needs traceable tool use and a governed skill catalog if identity work is going to remain reviewable.

Key terms

• Auth Wiring Drift: Auth wiring drift is the gradual mismatch between generated authentication code and the runtime assumptions that make identity flows work. It usually appears in cookie scope, redirect targets, server-side request forwarding, or SDK initialisation, and it creates failures that look like application bugs even when the underlying cause is trust boundary misalignment.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agent Session Trace: An agent session trace is a structured record of tool calls, file operations, and execution outcomes made by a software agent during a session. It provides the evidence needed to reconstruct privileged actions without exposing full secrets or payloads, which makes it a core governance artefact for agentic development.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.

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.

👉 The full Ory article covers the plugin workflow, local stack setup, and trace model in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.