The Third-Party App You Approved May Have More Access Than You Think

A supplier integration gets approved because it needs to exchange data with an internal application. An administrator grants the requested permissions, the connection works and everyone moves on. Months later, the integration may still have access to sensitive information or administrative functions that its original purpose never required.

That quiet accumulation of access deserves attention. A third-party application does not need an employee to sign in interactively every time it accesses a cloud service. Its application identity can use previously granted permissions in the background, making excessive access harder to spot through ordinary user-account reviews.

A warning published by the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), last reviewed on 26 October 2026, describes a campaign involving compromised third-party application identities and access to customer cloud environments through permissions already granted to those applications. The agency reported that the activity included attempts to maintain access and modify privileges. It also noted that AI can increase the speed and scale of these operations.

The underlying weakness was familiar: trusted access with permissions that could be abused. AI changes the pace at which such access may be exploited. That makes the integration itself a relevant part of an organisation's security testing scope.

Test the relationship, not just the application

A conventional web application assessment may examine exposed endpoints, authentication and application logic. Those checks remain necessary, but they can leave a blind spot if the assessment does not include the identities and permissions connecting the application to other services.

An authorised assessment should examine the organisation's own cloud tenant and approved integration paths. It should ask what a compromised application identity could reach, what actions its permissions allow and whether the organisation would notice unusual activity.

Four areas deserve particular attention:

• Application inventory: Identify active app registrations, service principals, OAuth grants, API credentials and certificates. Remove integrations that are no longer required.

• Permission scope: Compare each application's granted permissions with its actual business function. Review high-risk consent grants and excessive administrative privileges.

• Access paths: Determine whether an application identity can reach sensitive data, invoke privileged operations or access additional services beyond its intended role.

• Detection and revocation: Check whether logs capture unexpected consent grants, credential additions and privilege changes. Under an approved test plan, verify that access can be revoked and that related credentials or persistence mechanisms are addressed.

The ACSC specifically recommends limiting application permissions, requiring administrator approval for high-risk OAuth permissions, protecting application credentials and monitoring non-human identities alongside user accounts. Its cloud security guidance also reminds organisations that cloud security responsibilities are shared, while customers remain accountable for protecting their own data.

Where AI-assisted penetration testing fits

NIST's Technical Guide to Information Security Testing and Assessment sets out a structured approach to planning technical tests, analysing results and developing mitigation strategies. The guide recognises that testing techniques have different benefits and limitations, which is a useful principle when assessing complex cloud integrations.

AI-assisted penetration testing can support a broader assessment workflow by helping security teams examine authorised targets and identify potential paths that deserve closer investigation. Its usefulness depends on the testing scope, available access and the platform's supported assessment surfaces. A supplier's external systems must remain out of scope unless separate authorisation has been obtained.

For security leaders, the practical question is whether the assessment can show how far an approved integration's access could reach, under clearly defined rules. A list of permissions is a starting point. Understanding the consequences of those permissions is the real security work.

Bronyx AI, ITSEC's AI-assisted autonomous penetration testing platform, is relevant to organisations exploring how AI can support their authorised security testing programmes. Define the assets and identity paths to be assessed, confirm the permitted testing boundaries and evaluate the results against your organisation's risk priorities.

Explore Bronyx AI at https://bronyx.ai/.
 

References

1. Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), AI-enabled attacks highlight supply chain and cloud security risks, last reviewed 26 October 2026. https://www.cyber.gov.au/blog/ai-enabled-attacks-highlight-supply-chain-and-cloud-security-risks

2. Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), Cloud computing security for tenants, published 18 December 2014, last reviewed 18 January 2024. https://www.cyber.gov.au/publication/cloud-computing-security-for-tenants

3. National Institute of Standards and Technology (NIST), Technical Guide to Information Security Testing and Assessment, Special Publication 800-115, September 2008. https://csrc.nist.gov/pubs/sp/800/115/final