Why do custom web apps and APIs create more risk for agentic attackers than patched commodity software?

Why bespoke apps and APIs are harder for agentic attackers to reason about

Custom web apps and APIs are riskier because the attacker is not just probing for common bugs, they are trying to infer your organisation's business rules, hidden trust assumptions, and permission boundaries. That makes brittle logic, inconsistent enforcement, and edge-case workflows especially attractive, since those are the places where an autonomous system can connect valid actions into an abusive sequence.

Commodity software is usually attacked through known classes of weakness, then patched and defended at scale. Bespoke systems do not benefit from the same vendor hardening cycle, and the exact control points often live in application code, API policy, and downstream integrations that the owner must test, monitor, and fix.

The practical consequence is that "secure by patching" works much better for standardised products than for custom flows. In a custom estate, the question is less "is the software patched?" and more "can the system be made to do something unintended while still passing normal checks?"

Where custom logic creates the attacker’s opening

The main weakness is not usually an obvious exploit, it is the gap between what the application allows and what the business intended. A custom API may expose the right endpoint, accept a valid token, and still allow the wrong object, action, or workflow state because the authorisation rule is incomplete or expressed in the wrong place.

This is why bespoke systems are difficult for scanners to assess. Tools can detect missing patches, exposed services, or generic injection patterns, but they struggle to model whether an approval workflow can be replayed, whether a multi-step process can be chained, or whether a low-privilege action becomes powerful after the third hop. The risk rises whenever the application mixes business logic with delegated access and assumes the caller will behave like a human operator.

That is also why API authorisation flaws matter so much in custom estates. Broken object-level or function-level checks are not just coding defects, they are routes for an automated attacker to turn one legitimate capability into broader abuse.

Why patched commodity software is still safer, but not safe enough

Commodity software has a different security profile because its weaknesses are more widely observed, more consistently triaged, and more likely to be patched by the vendor. That does not make it immune, but it reduces the long-tail of organisation-specific logic errors. When a flaw is public, defenders also tend to get signatures, advisories, and patch guidance quickly.

Custom software shifts that burden inward. The organisation owns the review cycle, the threat model, the regression testing, and the rollback decision. If the application or API sits on a critical workflow, patching alone may not remove the exploitable condition, because the true issue may be an over-broad entitlement, a missing approval gate, or an integration that trusts an upstream signal too much.

For agentic attackers, that is valuable because the exploit path does not need to look like classic malware. It can look like ordinary use, repeated at scale, across enough combinations of inputs and workflow states to discover a path the designers did not anticipate. NIST CSF 2.0 is useful here because it forces teams to treat application governance, control monitoring, and recovery as part of the security outcome, not just patch management.

Risk and Threat Considerations

Custom applications and APIs increase exposure because the most damaging failures are often semantic, not technical. An attacker can abuse valid authentication, legitimate endpoints, and ordinary-looking requests if the underlying workflow permits privilege drift, object confusion, or multi-step abuse.

Failure mechanism: The application accepts a request that is syntactically valid but semantically over-permissive, then allows the attacker to chain business logic, delegated access, or inconsistent authorisation into actions the owner never intended.

Impact: The result can be unauthorised data access, workflow abuse, fraudulent actions, privilege expansion, or downstream compromise of adjacent systems that trust the custom integration.

Practitioner Guidance

What to prioritise: Focus review effort on the custom control points that make the application unique, especially object-level checks, function-level permissions, approval flows, and cross-service trust boundaries. Those are the places where a generic vulnerability scan is least informative and where a misstep has the highest blast radius.

What to verify: Test the application as a sequence of valid business actions, not just as isolated endpoints. If a caller can complete a high-impact workflow by combining several low-risk operations, treat that as a design defect even when every individual request looks legitimate.

Practitioner takeaway: The security gap in bespoke software is usually not "unknown software" but "known logic that was never fully constrained", so the safest control is to verify the authorisation model at the workflow level, not just at the endpoint level.

Related resources from NHI Mgmt Group

• Why do delegated web apps create governance risk for IAM teams?
• Why do desktop OAuth clients create more governance risk than web apps?
• Why do agentic browsers create risk beyond normal web automation?
• Why do custom applications create more identity governance risk than packaged SaaS apps?