Accountability sits with the organisation that owns the environment and its access model, not with the attacker or the integration category. Security, IAM, and platform teams need clear ownership for approval, monitoring, and review of OAuth apps, tokens, and webhooks. Without that governance, excessive permissions can remain in place long enough to cause durable damage.
Why This Matters for Security Teams
When a compromised integration changes repository settings or adds unauthorized access, the issue is not just technical misuse. It is a governance failure around who can approve, monitor, and revoke non-human access. That is why NHI Management Group treats integrations, OAuth apps, API keys, and webhooks as first-class identities, not just tooling. NIST’s Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both point to the same operational reality: unattended machine access becomes durable when ownership is unclear.
NHI risk is also amplified by how common over-privilege is. In Ultimate Guide to NHIs, NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which means a single compromised integration can move from a narrow foothold to broad repository control very quickly. In practice, many security teams encounter this only after branch protection has been relaxed, secrets have been exposed, or access has already been granted to additional collaborators rather than through intentional review.
How It Works in Practice
Accountability should be assigned to the organisation that owns the environment and its access model, but the operating model has to be explicit. A secure setup defines who approves an integration before it is installed, who reviews scopes after installation, who watches for unusual write activity, and who removes access when the integration is no longer needed. That is standard governance for NHIs, not an optional layer.
In practice, the right control set combines inventory, least privilege, and ongoing review. Integrations should be registered as managed NHIs with named owners, purpose, scope, and expiration. Approval should be tied to business need, not convenience. Runtime monitoring should look for repo setting changes, new deploy keys, collaborator grants, webhook edits, and permission expansion. Where available, use short-lived tokens, scoped OAuth grants, and just-in-time access so the integration does not keep permanent authority after the task ends. The 52 NHI Breaches Analysis shows how often compromised machine access turns into broad operational damage once controls are missing.
- Assign a business owner and a technical owner for every integration.
- Review OAuth scopes, webhook permissions, and repository write paths before approval.
- Log and alert on changes to settings, collaborators, branch protection, and secrets.
- Revoke access immediately when an integration is disabled, replaced, or untrusted.
The pattern is simple: if the organisation cannot answer who approved the access, who can revoke it, and who checks it after deployment, the integration is already over-privileged. These controls tend to break down in fast-moving DevOps environments where app sprawl, inherited permissions, and shared admin roles make ownership ambiguous.
Common Variations and Edge Cases
Tighter integration control often increases operational overhead, requiring organisations to balance deployment speed against revocation discipline and review quality. That tradeoff is real, especially in engineering teams that rely on automation to ship quickly. Current guidance suggests that exceptions are acceptable only when they are documented, time-bound, and monitored.
There is no universal standard for every platform yet, but the practical rule is consistent: the more a tool can modify repository settings, the more it should be treated like a privileged NHI. Third-party CI/CD apps, code scanning tools, support bots, and internal automation can all be legitimate, but each needs separate accountability and scope review. For breach context, NHI Mgmt Group documents cases such as the BeyondTrust API key breach and Microsoft SAS Key Breach, both of which show how machine credentials can create lasting access if not contained quickly. The operational answer is to treat every integration as revocable, observable, and owned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers discovery and inventory of non-human identities like integrations and tokens. |
| OWASP Agentic AI Top 10 | A-04 | Addresses tool-using autonomous or semi-autonomous integrations with execution authority. |
| CSA MAESTRO | TRUST-02 | Supports governance for autonomous access paths and delegated actions. |
| NIST AI RMF | Risk governance is needed when integrations can act with broad authority. |
Catalog every integration, owner, scope, and expiry so repository-changing access is visible and reviewable.
Related resources from NHI Mgmt Group
- Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
- How should security teams think about a compromised integration like Drift?
- Who is accountable when AI-assisted remediation changes access or privilege settings?
- Who is accountable when a third-party access integration is misconfigured and exposes cloud projects to unauthorized access?
