AI pentesting economics are the real build-vs-buy decision

At a glance

What this is: This is an analysis of why AI pentesting is operationally harder to build in-house than the demo suggests, with cost, reliability and model dependency driving the decision.

Why it matters: It matters because security teams evaluating AI-assisted testing need to treat orchestration, validation and lifecycle management as governance issues, not just engineering choices.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Synack's analysis of the build-vs-buy decision for AI pentesting

Context

AI pentesting is attractive because it promises faster and broader security testing, but the governance gap appears once teams move from a proof of concept to repeatable operations. In practice, the hard part is not getting a model to produce an answer once, but making the output dependable across changing workflows, changing models and changing cost structures.

For identity and access teams, this is not just an AI tooling question. The operational burden sits around human validation, workload identity for the testing pipeline, secrets handling and lifecycle control for model dependencies. That intersection is where AI security starts to look like an identity governance problem as much as an automation problem.

Synack frames the challenge as a build-vs-buy decision, but the underlying issue is broader than one vendor's model choice. Most organisations can prototype AI-assisted testing; far fewer can own the reliability, validation and lifecycle management needed to make it a sustained control.

Key questions

Q: How should security teams decide whether to build or buy AI pentesting capabilities?

A: Teams should compare the full operating cost, not just the first prototype. Building means ongoing model tuning, orchestration, token management, guardrails, and validation work every time the underlying model changes. Buying makes more sense when the goal is continuous coverage and the internal team needs to stay focused on assets, risk decisions, and remediation ownership.

Q: Why do AI agent workflows need identity governance for oversight?

A: Because oversight only works when the organisation can prove who approved an action, what they saw, and why they intervened. Identity governance supplies the enforcement layer through authentication, authorisation, and audit evidence. Without that layer, the human is present but not operationally in control.

Q: What do security teams get wrong about AI safety testing?

A: The common mistake is treating AI safety testing as if it were just another security scan. It is not. Safety testing is about proving how a model or agent fails under pressure, while traditional security tooling is about who can access the system. Those are different governance questions and need different evidence.

Q: When does AI pentesting become too costly to run in-house?

A: It becomes expensive when the team moves from occasional tests to repeated enterprise-scale usage. The cost drivers are not only model tokens and compute, but also orchestration, monitoring, human review and re-engineering when providers change the underlying model lifecycle.

Technical breakdown

Why AI pentesting demos do not reflect operating cost

A demo measures whether an AI workflow can produce a useful output once. A production security capability has to prove repeatability, observability and resilience across many runs, different targets and changing prompts or models. Costs then accumulate in tokens, compute, orchestration, monitoring and human review. The economic error is treating the first successful run as evidence of long-term affordability or operability. In security testing, a cheap first result can mask expensive ongoing control overhead.

Practical implication: model the cost of repeated execution, not the cost of the first proof of concept.

How model dependency changes the risk profile of in-house AI testing

When an in-house build relies on a third-party foundation model, the organisation inherits that provider's lifecycle decisions. Pricing changes, API updates, deprecations and retirements can all alter test reliability or force re-engineering. That creates a hidden dependency chain that looks like a normal software integration at first, but behaves more like a managed control plane over time. The risk is not only technical drift, but also governance drift when the business assumes ownership without recognising the external dependency.

Practical implication: classify foundation models as governed dependencies with lifecycle and fallback plans, not as static inputs.

What makes AI pentesting results trustworthy

Trustworthy AI pentesting is not the model alone. It is the surrounding control system: orchestration, safeguards, validation infrastructure, and where necessary, human expertise. That is similar to other high-risk security workflows where automation increases throughput but does not remove the need for assurance. The question is whether the workflow can prove that a finding is meaningful, reproducible and actionable. Without that layer, AI may generate output quickly, but it does not yet generate a dependable security decision.

Practical implication: separate content generation from security validation in the operating design.

NHI Mgmt Group analysis

AI pentesting is becoming an identity governance problem as soon as the workflow depends on third-party models and service credentials. The article is about cost and reliability, but the control surface includes model APIs, orchestration identities and the human validation chain. That means teams need to think about who or what can invoke the testing workflow, how access is bounded, and how lifecycle changes are governed. In practice, AI security testing inherits the same access-control discipline as other sensitive automation.

Model dependency is the named risk here, not model capability. The article makes clear that enterprises building on external foundation models inherit pricing changes, deprecations and retirements. That creates a specific governance gap: organisations may own the workflow while another party controls the underlying runtime. Practitioners should treat model lifecycle management as part of their control environment, because the dependency can silently alter reliability and cost.

Reliability debt is the right concept for in-house AI testing programmes. A proof of concept often hides the work required for monitoring, validation and re-tuning. Once the workflow is operational, every exception, edge case and model drift event becomes a permanent support obligation. The practical conclusion is that speed from AI is not a substitute for a sustainable control model, especially where findings inform security decisions.

Human validation remains the control that makes AI pentesting defensible. The article correctly separates impressive output from trustworthy output. In high-impact security testing, human oversight is not a temporary crutch but part of the assurance architecture. Practitioners should design for review, triage and challenge testing rather than assuming automation can self-certify its own findings.

AI pentesting will consolidate around operational maturity, not just model access. Organisations can access the same model APIs, but they do not automatically inherit the engineering depth required to sustain a service. That will favour programmes that can absorb validation, lifecycle and orchestration costs across the full control stack. The field is moving toward governed AI operations, not merely AI experimentation.

What this signals

AI-assisted security testing will push more organisations to formalise who owns model access, validation authority and workflow credentials. The governance problem is no longer whether an AI model can help, but whether the surrounding identity controls can keep the workflow trustworthy when the model, provider or pipeline changes.

Model dependency debt: this is the accumulation of lifecycle and governance obligations that appear when an organisation builds on someone else’s AI runtime. Practitioners should map those dependencies alongside other privileged integrations and make sure they are covered by access review, secret rotation and offboarding controls.

For teams already experimenting with AI in security operations, the next maturity step is to treat the pipeline like any other critical system. That means binding it to NHI Lifecycle Management Guide practices for ownership, rotation and retirement, rather than letting prototype convenience become a permanent control gap.

For practitioners

• Build a full run-cost model Estimate tokens, compute, orchestration, monitoring, validation and human review for repeated AI pentesting runs rather than a single pilot. Include rework costs when model outputs change or fail validation.
• Treat foundation models as governed dependencies Document model providers, API dependencies, version changes and retirement triggers in the same inventory used for critical services. Define fallback paths before a deprecation forces emergency engineering.
• Separate generation from validation Use AI to accelerate coverage, but keep an independent validation layer for exploitability, reproducibility and business relevance. That control should prevent unverified findings from entering remediation workflows.
• Apply identity controls to AI testing pipelines Restrict who can invoke pentesting workflows, rotate secrets used by agents and enforce least privilege on orchestration accounts. AI testing platforms still depend on service accounts and tokens that need governance.
• Define build-vs-buy criteria around control ownership Decide whether the team is prepared to own the reliability engineering, lifecycle management and validation burden over time. If not, the prototype should be treated as a learning exercise, not a production path.

Key takeaways

• AI pentesting becomes difficult to sustain when teams move from a one-off demo to repeated production use.
• The real cost is in reliability engineering, validation, lifecycle management and model dependency, not just the initial build effort.
• Security leaders should judge AI pentesting by control ownership and trustworthiness, not by whether the first result looks impressive.

Key terms

• Model dependency: The extent to which a product’s core function relies on an external AI model at runtime. In security tools, model dependency becomes a governance issue when the product cannot operate, validate, or recover if the provider changes access, availability, or behaviour.
• Reliability Engineering: The discipline of making an AI workflow behave consistently under real operating conditions. For security testing, it covers monitoring, repeatability, validation, fallback handling and exception management so that a promising prototype becomes a dependable control.
• Human Validation: A review step where a qualified person confirms whether an AI-generated finding is truly exploitable and relevant. It prevents false positives from entering remediation queues and keeps business context inside the decision process.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

What's in the full article

Synack's full blog post covers the operational detail this post intentionally leaves for the source:

• Detailed build-vs-buy reasoning from the perspective of a security vendor operating AI pentesting at scale
• Discussion of token consumption, orchestration overhead and the economics of repeated agentic workflows
• Examples of how model deprecation and pricing shifts affect product maintenance over time
• The webinar reference point where Synack and Dow discussed production-grade AI pentesting decisions

👉 Synack's full post covers the economics, reliability trade-offs and model dependency risks in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners apply lifecycle control to automation that depends on tokens, service accounts and delegated access.