Last updated: September 2026
AI application security is good at reviewing your code, but it cannot act as your identity provider. When a team asks Claude, Cursor, or another coding agent to “secure the app,” the useful work is review and remediation drafts. The non-negotiable work (who gets a token, for which API, at what assurance, and how you kill that access) still belongs in IAM.
This post is for platform and security leads who want AI help without confusing a pull request with a control plane.
What “secure my app with AI” usually means
Most AI AppSec loops look the same:
- Point an agent at a repo or a diff.
- Ask for vulns, dependency risk, unsafe defaults, missing tests.
- Accept or rewrite the suggested patches.
That is real value. Agents are fast at spotting missing input validation, outdated libraries, hardcoded secrets in samples, and “TODO: add auth” stubs. They are also useful for drafting threat notes and checklists.
Those loops stop at the edge of runtime identity.
An agent can suggest adding an Authorization header check. It cannot decide whether your OAuth client should be public or confidential, whether access tokens should be audience-bound to api://billing, whether admin routes need a higher authentication context class, or whether yesterday’s leaked refresh token is still valid. Those decisions live in your identity layer: the authorization server and the policies around issuance and revocation.
Working definition: AI AppSec improves how you write and review software. IAM decides whether a caller is allowed to act, under what constraints, and how you take that ability away.
Identity failures AI code review will not catch
Audience and scope mistakes
A common failure mode is a single “platform” audience that every microservice accepts. The code review looks fine: every service validates JWT signature and expiry. The identity design is wrong: a token minted for the docs site still opens billing.
AI review of one service rarely sees the token contract across services. Fixing that is an IdP and resource-server policy problem (narrow audiences, explicit scopes, reject-by-default), not a missing if in one handler.
Long-lived tokens and missing step-up
Agents often suggest “add MFA at login.” Login MFA does not protect POST /payouts six hours later if the access token is still valid and the API never checks authentication age or ACR. Step-up is an issuance and enforcement problem: fresh authentication for sensitive actions, short access-token lifetimes, and APIs that refuse stale assurance.
Service accounts shared across agents and humans
Paste a client secret into an agent config, a CI variable, and a human’s laptop “just for debugging,” and you no longer have an inventory. Code review might flag the secret in git. It will not invent a non-human identity program: one client per agent class, tight scopes, rotation, and revocation without redeploying a model.
We wrote about agent authentication patterns separately in Authenticating AI Agents with Keycloak. The point here is simpler: AI AppSec does not replace that design work.
A practical split of ownership
Let AI assist on code and policy drafts
Good uses of coding agents for security:
- Drafting regression tests for authz paths.
- Reviewing realm export JSON or Terraform for obvious footguns (you still gate applies).
- Turning a human checklist into a PR (PKCE on public clients, disable direct access grants where unused).
- Summarizing changelog risk when you bump an IdP version.
Keep humans (or policy engines) in the loop before anything hits production.
Keep issuance, MFA or ACR, and revocation in the IdP
Own these in the identity control plane, whether you self-host Keycloak or run managed upstream Keycloak:
| Concern | Belongs in |
|---|---|
| Client type, PKCE, redirect URIs | IdP client config |
| Audiences and scopes | IdP + resource servers |
| MFA / step-up / ACR | IdP flows + API policy |
| Token lifetimes and refresh | IdP realm/client settings |
| Kill switch after leak | IdP revocation / logout / client disable |
| Exportable config for review | Realm export / IaC |
Fine-grained object-level authorization may still sit in a policy engine beside the IdP, but issuance stays in IAM.
Keycloak as the reviewable control plane
Open-source Keycloak (and upstream-compatible managed offerings) help here because configuration is inspectable and exportable. You can hand a redacted realm export to a coding agent and ask for findings against a checklist, then apply changes through review like any other config. Identity policy becomes something you can version, diff, and rehearse, not only click in a vendor console.
If you want a human baseline before you involve an agent, use our Keycloak security audit and hardening checklist. For protocol depth on OIDC itself, see OpenID Connect explained for developers.
Managed platforms still matter for the runtime you do not want to be paged for: upgrades, HA, backups, edge controls.
What to do this week
- Pick one sensitive API and write down the required audience, scopes, and step-up rule in plain language.
- Confirm the IdP actually issues that contract (and that other audiences fail closed).
- Use an AI agent only to draft tests and to review a redacted realm export or Terraform plan against your checklist.
- Keep production applies behind the same review path you use for infrastructure.
Run the IdP without running the cluster
If you want that control plane on upstream Keycloak without running the cluster, Skycloak is managed Keycloak with exportable realms and SOC 2 Type II, ISO 27001, GDPR, and HIPAA. Start the 21-day free trial (no card), or pick the 7-day Expert path if you want a dedicated cluster from day one.