TL;DR: Akeyless describes an AI review pipeline that extracts findings into reusable skills, then applies those skills to every pull request to test authentication, secrets handling, and trust-boundary regressions automatically. The real issue is not review speed but whether security knowledge can be encoded as durable governance without mistaking detection for control.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “How We Turned AI Agents Into Security Researchers at Akeyless”.
Key questions
Q: What is the difference between AI governance and code review?
A: AI governance decides what data, tools, and use cases are allowed.
Q: Why do learned security skills matter for pull request reviews?
A: They matter because they let a reviewer carry forward the reasoning behind prior findings instead of starting from scratch on each change.
Q: How should teams decide whether an AI reviewer can approve security-sensitive changes?
A: Teams should allow approval only where the model’s findings are tied to explicit tests, clear ownership, and a defined fallback to human review.
Practitioner guidance
- Define review-to-control boundaries Specify which identity and secrets findings the agent may recommend and which outcomes still require human approval.
- Convert repeated findings into governed skills Store recurrent review logic as controlled policy content with ownership, versioning, and review criteria.
- Require end-to-end auth-flow tests Validate complete token issuance, validation, and secret retrieval paths before merge, not just the changed lines in a pull request.
Bottom line: The article describes a learning-agent model for pull request review, but the deeper issue is whether security reasoning can be made persistent and governable across changes.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The exact four-stage pull request pipeline, including review, test, re-test, and final merge gating
- The mechanics of converting an investigation into a reusable skill that persists across future reviews
- Examples of how the agent evaluates token validation, trust boundaries, and response leakage in code
- The platform-specific reasoning behind distributed trust, gateway boundaries, and downstream blast radius
👉 Read Akeyless's analysis of learning agents for pull request security reviews →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Security review becomes a governance problem the moment findings are promoted into persistent agent memory: once investigative logic is reused across every pull request, review stops being a one-time control and starts behaving like a governance layer. That is useful, but it also changes the trust model. The organisation now has to govern what the agent learns, when that learning is authoritative, and how exceptions are handled when the learned skill is wrong or incomplete. The implication is that learned review logic needs lifecycle ownership, not just model tuning.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: When does AI review create a false sense of security?
A: It creates a false sense of security when teams treat good findings as proof that the underlying control is sound. A strong reviewer can still miss compound failures across caching, validation, or routing, so end-to-end auth-flow verification remains necessary before merge.
👉 Read our full editorial: Akeyless uses learning agents to review PRs and compound security