Should Identity and Security Workflows Use AI at All?

A product team can add AI to almost any workflow on a whiteboard. That does not mean it should.

Authentication, phone verification, dependency upgrades, and security release maintenance have a different character from open-ended research or drafting. They involve explicit inputs, known protocols, reviewable state changes, and consequences that are difficult to explain away after the fact. For these jobs, ordinary software is often the more credible starting point.

That is the narrow decision in this article: when should a technical team keep an identity or security workflow deterministic instead of introducing an AI component?

The supplied sources do not provide model versions, model pricing, context limits, or API behavior. They therefore cannot support a recommendation for a particular model, agent framework, or AI vendor. What they do support is a practical baseline: use documented web APIs and disciplined release maintenance first, then consider AI only where it solves a clearly defined problem without weakening control.

Start with deterministic identity flows, not an AI agent

A sign-in system has a concrete user problem: let an authorized person access an account while reducing friction and protecting the account. The web identity material covers passkeys, WebAuthn, autofill, password-manager integration, SMS one-time passwords, and the WebOTP API. These are explicit mechanisms with documented browser and server responsibilities, rather than an invitation to delegate authentication decisions to a general-purpose model. web.dev’s identity resources describe these implementation paths, including passkey registration and management, WebAuthn server-side guides, WebOTP, and form best practices.

That distinction matters. A deterministic identity flow can define what counts as a valid credential, which origin or relying party is involved, when a code expires, and which server-side checks are required. A model may help a team write documentation, inspect test cases, or classify support questions, but the supplied sources do not establish that it should decide whether a login succeeds.

This is an interpretation of the source material, not a claim that AI has no possible role in identity products. The decision criterion is narrower: if a task already has a standard protocol and a pass/fail boundary, introducing a probabilistic layer needs a specific benefit and an evaluation plan. Without both, ordinary software is easier to audit and easier to replace.

The same logic applies to security maintenance

The Python Insider source reports expedited security releases for Python 3.15, 3.14, and 3.13: versions 3.15.1, 3.14.9, and 3.13.17. It also says those releases upgrade bundled pip to 26.2.2, which includes certifi 2026.10.19 to address the eMudhra / emSign CA certificate security incident. The post recommends upgrading pip and uv for existing virtual environments and provides version-specific installation commands. Python Insider’s release notice is the supplied primary source for those details.

The operational lesson is not “automate everything with AI.” It is to make the maintenance path explicit:

1. Identify the Python versions and virtual environments in scope.
2. Check the relevant security release and its stated dependency changes.
3. Apply the documented upgrade path.
4. Test the application and certificate-dependent flows.
5. Record what changed, who approved it, and what remains unverified.

A script can make those steps repeatable. A conventional dependency tool can compare versions. A CI pipeline can run tests and block a release. An AI assistant could potentially summarize release notes or propose an upgrade checklist, but the provided evidence does not establish its accuracy, pricing, context window, or API contract. Those unknowns are not a reason to ban such a tool; they are a reason not to make it the authority for a security change.

Use community documentation as a review surface

The MDN sources describe an open, collaborative project documenting HTML, CSS, JavaScript, and Web APIs. They also describe contribution workflows involving GitHub issues, pull requests, discussions, reviews, repositories, localization, and community participation guidelines. MDN’s community overview and MDN’s community resources support a useful engineering principle: technical knowledge improves when changes have a visible place for discussion and review.

That principle is relevant to AI-assisted development. If a model helps draft an authentication implementation or security note, the output should enter an ordinary review process. It should not bypass the maintainers, issue tracker, tests, or documentation that make the decision inspectable.

The source does not say that MDN endorses AI-assisted coding, so this is an application of its described collaboration model. The practical boundary is straightforward: AI may be an input to a review process; it should not silently become the process.

Where automation helps—and where it stops

A useful design separates low-risk repetition from high-consequence judgment.

Reasonable automation candidates include:

• locating Python environments that need attention;
• checking whether a documented package or interpreter version is present;
• running regression and authentication tests;
• collecting logs for a human reviewer;
• drafting a migration checklist from supplied release notes;
• organizing identity documentation and open implementation questions.

Keep explicit human review around:

• changes to relying-party or origin configuration;
• credential registration and recovery policy;
• certificate and trust-store changes;
• production dependency upgrades;
• decisions that expose personal, authentication, or operational data to an external service;
• exceptions where tests pass but the security impact is unclear.

This boundary is an interpretation, because the sources do not prescribe an AI governance model. It follows from the nature of the documented tasks: identity APIs, authentication forms, and security releases need precise configuration and verification. A human reviewer should be able to see the proposed change, reproduce the checks, and reject it without needing to trust an opaque narrative.

Privacy is part of the technical design

Identity and security workflows can contain account identifiers, recovery details, phone numbers, logs, source code, package inventories, and incident information. The supplied sources do not state how any AI provider stores, trains on, or processes those inputs. Therefore, no provider-specific privacy conclusion is justified here.

The decision should instead begin with a data map. For every proposed AI step, ask:

• What exact data enters the system?
• Can the task run on redacted or synthetic examples?
• Is the data necessary for the proposed output?
• Where is the result stored?
• Can a reviewer reconstruct the decision without sending the underlying secret?
• What happens if the service is unavailable or returns an uncertain answer?

If the workflow cannot answer those questions, the safer default is a conventional tool or a manual review. This is not an anti-AI position. It is a requirement to know what crosses the boundary before optimizing the work inside it.

Unit economics: count review, not just API calls

A model cost estimate would require supplied pricing and usage assumptions, and none are present here. It would be misleading to invent a per-token price or claim savings.

The calculation should still be explicit. Let:

• Cₐ = AI service cost per item;
• Cᵣ = human review cost per item;
• Cᵢ = integration, monitoring, and failure-handling cost per item;
• Cₘ = cost of the ordinary deterministic alternative per item.

The AI-assisted route is economically preferable only under the stated assumptions if:

Cₐ + Cᵣ + Cᵢ < Cₘ

That comparison is incomplete unless it includes the cost of a missed security issue, an incorrect authentication change, rework, and an outage. Those values are business assumptions, not facts from the supplied sources, so they must be measured or stated rather than smuggled into a confident ROI claim.

For many identity tasks, the ordinary alternative may have a higher initial implementation cost but a clearer long-term review path. For release maintenance, the documented upgrade commands and test pipeline may already cover most of the repeatable work. An AI layer needs to remove a real bottleneck—not merely add a new component to supervise.

A decision path for technical founders and operators

Use this sequence before adding AI to an identity or security workflow:

1. Name the user or business problem. Is the problem failed sign-in, slow verification, unclear documentation, missed upgrades, or excessive support work?
2. Check for a standard mechanism. The web identity sources provide documented paths for passkeys, WebAuthn, autofill, and WebOTP. Start there where they fit.
3. Define the acceptance test. Specify what success, failure, rejection, rollback, and human escalation mean.
4. Build the deterministic baseline. Use ordinary application code, browser APIs, package tooling, tests, and reviewable change management.
5. Map sensitive data. Remove secrets and personal data from any proposed AI input unless the business and security review explicitly allow it.
6. Add AI only to a bounded step. Documentation triage or checklist drafting is a different risk category from credential approval or production configuration.
7. Measure total cost. Include review, integration, monitoring, rework, and failure handling—not just service usage.
8. Write the invalidation condition. Stop or redesign the recommendation if reviewers cannot reproduce the result, the error rate is unacceptable, privacy controls are inadequate, or the baseline is already cheaper and clearer.

What would invalidate this recommendation?

This recommendation would change if a specific AI system had verified accuracy on the exact identity or maintenance task, a documented API and pricing model, acceptable privacy controls, and a review process that reduced total operational effort without weakening security. None of those supporting details is present in the supplied excerpts.

Until then, the defensible default is modest: use ordinary software for protocol enforcement, authentication decisions, dependency application, and test gates. Consider AI around the edges where it can assist people without becoming the unreviewed authority.

The useful question is not whether a workflow can contain AI. It is whether the workflow becomes safer, clearer, and economically sound after AI is added. If you are assessing an identity flow, security maintenance process, or AI product boundary, I can help turn that question into a technical audit, implementation plan, or reviewable decision record.

Official sources

• Inside Java — Viktor Klang
• Python Insider — Python 3.15.1, 3.14.9 and 3.13.17
• web.dev — Identity
• MDN Web Docs — Community
• MDN Web Docs — Community resources