Autonomous business logic testing exposes access-control gaps in apps

At a glance

What this is: This analysis shows how an autonomous hacking agent can find business-logic and access-control flaws that conventional scanners miss.

Why it matters: It matters because IAM, application security, and PAM teams need to detect when valid sessions, roles, or tokens still allow the wrong user to act across business workflows.

👉 Read Ethiack's analysis of Hackian's autonomous business logic testing

Context

Business logic flaws are security failures where an application behaves as designed at the protocol level but still violates the intended access rule. In these cases, authentication can be present, endpoints can respond normally, and scanners can still miss the real problem because the vulnerability lives in workflow meaning rather than syntax. For IAM and application security teams, that creates a gap between technical control presence and actual authorisation correctness.

The article’s core point is that multi-identity testing changes the quality of validation. When a tool can compare what an admin, guest, or unauthenticated user should see, it can surface broken object-level authorisation, privilege bleed, and hidden metadata exposure. That is a genuine IAM and application security intersection, because the failure is not just in code but in access decision enforcement.

Key questions

Q: What breaks when identity controls are not tied to business value?

A: When identity controls are not tied to business value, they are easier to delay, underfund, or scope too narrowly. Teams may keep legacy access paths, tolerate over-privileged accounts, or postpone rotation work because the cost of inaction is not expressed in financial terms. That usually produces more exposure than the organisation realises.

Q: Why do multi-identity workflows expose gaps that single-user testing misses?

A: Because many authorisation bugs only appear when two sessions interact with the same object, token, or parameter. A single user path can look correct while cross-user reuse reveals hidden permissions, leaked metadata, or privilege confusion. Testing with distinct identities is the fastest way to surface whether access boundaries really hold in practice.

Q: How do you know if application authorisation is actually working?

A: Look for consistent denial of actions, objects, and metadata across different roles and sessions. If a guest can enumerate private records, or an unauthenticated session can retrieve configuration details, authorisation is failing even if authentication succeeds. The control works only when the application enforces identity context at every decision point.

Q: Who is accountable when a workflow exposes data to the wrong user?

A: Accountability usually sits across application engineering, security testing, and IAM governance. Engineering owns the workflow logic, security owns validation and detection, and identity teams own role design and entitlement scope. When exposure happens, teams should trace whether the failure was in policy definition, implementation, or verification, then close the loop in release governance.

Technical breakdown

Why business logic flaws evade scanners

Conventional scanners look for known patterns such as injection, missing headers, or exposed services. They are effective at syntactic validation, but they do not understand whether a request is semantically allowed for the current role, object, or workflow stage. A response can be technically successful and still be an authorisation failure if the caller should not have been able to invoke it. This is why business logic testing often requires reasoning about user intent, object ownership, and sequence dependency, not just endpoint reachability.

Practical implication: add workflow-aware tests that validate who can do what, not just whether an endpoint returns 200.

How multi-identity testing surfaces authorisation gaps

Multi-identity testing means executing the same workflow as different users and comparing the resulting permissions, data exposure, and side effects. That approach is especially useful for broken access control, where a parameter or token from one session can be replayed in another. In practice, the technique exposes object-level privilege escalation, hidden metadata, and role confusion that static analysis cannot infer. For identity teams, this is the closest analogue to testing whether authorisation policy is enforced consistently across the application’s real decision points.

Practical implication: validate role boundaries with at least two distinct identities in every critical workflow.

Semantic validation for private data and infrastructure metadata

Semantic validation is the step where the tool asks whether the data returned by a successful request makes sense in context. An unauthenticated caller receiving infrastructure details, or a guest retrieving private branch metadata, is a governance failure even if the API behaved as implemented. This matters because exposed metadata often becomes reconnaissance fuel for later exploitation, especially when it reveals routes, identifiers, or analysis history. In identity terms, the issue is not just access to data, but access to data that should have been excluded by policy.

Practical implication: classify metadata alongside sensitive content and test whether unauthorised sessions can enumerate it.

Threat narrative

Attacker objective: The attacker wants to turn legitimate application behaviour into unauthorised visibility into private data, internal metadata, or workflow state.

1. Entry occurs through a normal application request that appears valid to the scanner but is not valid for the user’s intended role or privilege scope.
2. Escalation happens when the attacker reuses parameters, tokens, or object identifiers across identities to bypass access boundaries and retrieve data they should not see.
3. Impact is unauthorised disclosure of private project metadata or infrastructure details that can support further recon, targeting, or privilege abuse.

NHI Mgmt Group analysis

Business logic flaws are an authorisation problem, not just a testing gap. When an application returns the right technical response but to the wrong identity, the core failure is governance of access decisions. That is why application security and IAM teams need shared ownership of workflow validation, not siloed responsibility. The practitioner conclusion is simple: test authorisation as a business rule, not as a code pattern.

Multi-identity validation should become a standard control for any workflow that exposes objects, metadata, or state transitions. A single account view cannot prove whether role boundaries hold, because many failures only appear when two identities interact with the same object or endpoint. This is especially relevant where session tokens, project keys, or object IDs can be reused across contexts. Practitioners should treat cross-identity testing as part of release gating for sensitive workflows.

Semantic validation is the named control gap this article exposes. The problem is not whether the request succeeded, but whether the returned data was appropriate for the caller’s identity and business context. That gap sits at the intersection of access control, data exposure, and trust in application state. The practitioner conclusion is to validate meaning, not just syntax, before declaring a control effective.

Identity-aware attack simulation belongs inside application security programmes, not outside them. The article shows that autonomous agents can combine role mapping, parameter fuzzing, and workflow reasoning to find flaws humans and scanners both overlook. That makes them useful for validating least privilege, object-level access, and privilege separation at scale. The practitioner conclusion is to align offensive testing with IAM governance objectives.

For teams running PAM or high-risk access workflows, broken business logic can bypass the controls that look strongest on paper. If an application lets a low-privilege session query sensitive state, then elevated control elsewhere may not matter. This is the practical reminder that privilege is enforced at the application decision point, not only at login. The practitioner conclusion is to test control inheritance end to end.

What this signals

Business-logic validation is becoming an identity control, not just an application test. As workflows grow more dynamic, teams need to prove that access decisions remain correct across roles, objects, and state transitions. That means release gates should include identity-aware replay tests, especially where business actions can cross trust boundaries. The practical signal is that application testing and IAM governance are converging around the same failure modes.

Semantic exposure is the more durable risk than obvious exploitation. A response that leaks branch IDs, internal routes, or configuration details can be enough to support later abuse even if the main business record stays protected. Teams should therefore treat metadata classification as part of their access model, not as an afterthought. Where AI-assisted attack tooling can reason across identities, weak authorisation becomes easier to operationalise at scale.

Cross-identity testing belongs in the same governance conversation as least privilege and session scope. The control question is no longer whether a user is logged in, but whether their session can be misused to infer or act on another identity’s authority. For programmes that also govern AI agents, the lesson is sharper: any system that can switch context or chain actions needs explicit boundaries. That is why the OWASP Agentic AI Top 10 is increasingly relevant even for conventional application workflows.

For practitioners

• Test critical workflows with multiple identities Run the same business process as guest, standard user, and privileged user, then compare object visibility, action outcomes, and returned metadata. Focus on checkout, deletion, approval, and project administration flows where cross-user access bugs are most likely.
• Add semantic assertions to API testing Write tests that fail when an endpoint returns sensitive state to a session that is authenticated but not authorised for that object. Include metadata fields such as branch names, IDs, timestamps, and internal routes in the protected data set.
• Gate releases on access-control replay tests Before deployment, replay tokens, object IDs, and workflow parameters across identities to confirm that one user cannot inherit another user’s privilege or data view. Treat any cross-session reuse success as a release blocker.
• Classify metadata as sensitive by default Review infrastructure and branch metadata, configuration endpoints, and internal routes as security-relevant assets, not harmless support data. Where appropriate, require the same authorisation checks that protect primary business records.
• Link application testing to IAM review Use findings from business logic testing to update role definitions, session scope, and object-level entitlements. When a workflow failure appears, trace it back to the access rule that allowed the wrong identity to proceed.

Key takeaways

• Business logic flaws bypass conventional scanners because the failure sits in the access decision, not the endpoint signature.
• Multi-identity testing exposes authorisation failures that single-user validation cannot see, especially in workflows with object reuse and metadata exposure.
• Identity, application security, and PAM teams need shared release gates for semantic validation and cross-session replay testing.

Key terms

• Business Logic Flaw: A business logic flaw is a weakness in how an application handles intended behaviour, such as permissions, workflow order, or transaction state. These flaws often bypass signature-based checks because the problem is not a malformed input, but a legitimate action used in the wrong sequence or context.
• Multi-Identity Testing: Multi-identity testing is the practice of running the same workflow as different users and comparing what each identity can see and do. It is useful for finding broken authorisation, hidden data exposure, and privilege confusion that single-session validation often misses.
• Semantic Validation Gap: Semantic validation gap is the mismatch between what a filter sees in text and what an AI model understands as intent. It matters because an instruction can be rephrased, hidden in context, or embedded in retrieved content while still steering the model toward the same harmful action.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.

What's in the full article

Ethiack's full article covers the operational detail this post intentionally leaves for the source:

• Workflow-level examples of how Hackian maps user journeys before testing control boundaries
• Endpoint-by-endpoint detail on how branch metadata and infrastructure settings were surfaced
• The report’s description of how multiple identities were coordinated to probe access rules
• Timing and disclosure context around the SonarQube and n8n findings

👉 The full Ethiack article covers the SonarQube and n8n cases, plus the testing methods behind them.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a common framework for controlling high-risk access across modern environments.