Who is accountable for access decisions when third-party integrations and AI agents share business systems?

Why This Matters for Security Teams

When third-party integrations and AI agents share business systems, the hardest problem is not connectivity. It is accountability at the decision point: who allowed the access, on what basis, and with what runtime constraints. Static entitlements rarely capture that reality, especially when an agent can chain tools, change intent mid-task, or inherit a partner’s scope through delegation. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same operational issue: access control has to be evaluated as a live risk, not a one-time setup.

NHIMG research shows why this matters in practice. In the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, including access to unauthorised systems and sensitive data. That is not a theoretical gap. It means accountability must extend across product owners, identity teams, and system owners whenever shared business platforms are in play. In practice, many security teams encounter misuse only after the access path has already been exercised, rather than through intentional governance design.

How It Works in Practice

Accountability should be anchored to the organisation that owns the access layer and the data classification, but the control model needs to follow how the request is made. For humans, a role can often explain access. For agents and third-party apps, the better primitive is workload identity plus runtime authorisation. That means proving what the requester is with cryptographic identity, then deciding what it may do based on current context, policy, and task scope.

In practical terms, teams should separate three decisions. First, authentication: confirm the subject through OWASP Non-Human Identity Top 10 style controls, including secret hygiene and token provenance. Second, authorization: enforce policy at request time using context-aware rules rather than pre-approved broad roles. Third, revocation: issue just-in-time credentials with short TTLs and revoke them automatically when the task ends. This is especially important for agentic workflows because agents can pivot faster than human approval loops can respond.

Implementation usually includes policy-as-code, audit logs that capture the decision context, and integration-specific scopes that are narrower than enterprise-wide roles. Some organisations also use delegation records so that a partner app or AI agent can be traced back to the original business request. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio coverage shows why this matters: once tokens are stolen or over-scoped, blame is no longer just about the external actor, but about the missing guardrails that made the path possible. These controls tend to break down in deeply nested partner-to-partner integrations because ownership of the effective access path becomes blurred across multiple tenants and control planes.

Common Variations and Edge Cases

Tighter access governance often increases integration overhead, so organisations have to balance speed for partners and agents against the cost of stronger review, logging, and revocation. Current guidance suggests there is no universal standard for every shared-system scenario yet, so the right answer depends on whether the workload is deterministic, autonomous, or user-directed.

One edge case is delegated access through SaaS marketplaces or low-code automation. Another is an AI agent that appears to act “on behalf of” a user but actually accumulates privilege through tool chaining. In those cases, role-based approval alone is usually too blunt. Best practice is evolving toward per-task authorization, bounded scopes, and continuous validation of claims and purpose. The Replit AI Tool Database Deletion incident is a reminder that system ownership matters as much as intent when an agent can execute destructive actions quickly.

For organisations with mixed human, partner, and agent access, the most reliable model is shared accountability with clear control ownership: business owners define acceptable use, identity teams enforce proof and scope, and platform teams enforce technical guardrails. The operational question is not whether a third party or agent touched the system, but whether the organisation could explain and constrain that access before the action occurred.

Related resources from NHI Mgmt Group

• How should teams govern access when AI agents and service accounts share the same business systems?
• How should security teams govern third-party AI agents that use OAuth access?
• Who is accountable when third-party access to OT systems is over-permissioned?
• Who should be accountable for third-party access that can affect patient systems?