They should define a shared governance model with separate control objectives. The identity team should own provisioning, authorization, auditability and revocation, while the AI assurance team should own adversarial testing, runtime monitoring and failure-mode analysis. Common reporting helps, but the controls should not collapse into one programme because they answer different risk questions.
Split ownership works only when the control model is split too
When AI access and AI safety sit in different teams, the failure to avoid is organisational overlap without control clarity. Access ownership is about who can provision, approve, revoke, and review authority. Safety ownership is about how the system is tested, monitored, and constrained when it behaves badly. If one team is asked to carry both risk questions, blind spots usually appear.
The practical fix is a shared governance model with explicit control boundaries. The identity function should manage provisioning, authorization, and revocation for AI access, while the assurance function should own adversarial testing, runtime monitoring, and failure-mode analysis. That separation keeps accountability clear without forcing one workflow to answer two different questions.
Common reporting still matters, but the reporting layer should not replace control ownership. A single dashboard can show who has access, what was tested, what failed, and what was remediated, yet the underlying approvals and tests should remain owned by the team best placed to act on them. That is especially important when AI systems are using tokens, API keys, or other identity-bearing material that needs both tight access control and separate misuse detection.
What the boundary should look like in practice
Where the boundary is drawn well, the identity team can answer: who created the access, who approved it, what scope it has, when it expires, and how it is removed. The AI assurance team can answer: what prompts, tool calls, outputs, jailbreak paths, and failure modes were tested, and what runtime signals show the system is drifting into unsafe behaviour. The two records should line up, but they do not need to be merged into one process.
That distinction is also useful when access is machine driven rather than human driven. If an AI system is reaching tools, portals, or datasets, the access question is not the same as the model-safety question. A model can be well tested and still over-entitled, or tightly scoped and still unsafe under adversarial input. Treating those as separate control objectives prevents the organisation from confusing “we can observe it” with “we can trust it.”
For that reason, many teams benefit from a simple ownership rule: access decisions are lifecycle decisions, safety decisions are assurance decisions. If the issue is whether authority should exist, who can grant it, or how quickly it can be withdrawn, it belongs with identity and access management. If the issue is whether the model or agent behaves safely under stress, attack, or ambiguity, it belongs with AI assurance. The governance model should preserve both views rather than averaging them into one.
Governance breaks down when ownership follows the org chart instead of the risk
The main organisational failure is not that the teams are separate, it is that their controls are often treated as interchangeable. They are not. Access controls are preventive and revocation-focused; safety controls are evaluative and monitoring-focused. If reporting, change approval, and incident response all flow through one committee, the team tends to optimise for process completion rather than control effectiveness.
Another common failure is shared language without shared evidence. “Approved” should mean something different for access than for safety. For access, approval should be backed by entitlement scope, owner, expiry, and revocation path. For safety, approval should be backed by testing coverage, baseline behaviour, and monitored failure indicators. The separation between authentication, authorization, and verification is a useful mental model even when the system is not a traditional web application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI access ownership directly concerns delegated authority and privilege abuse. |
| Recommendation — Separate access approvals from safety review to prevent privilege misuse by agents. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AI access depends on lifecycle control of credentials, tokens, and revocation. |
| AU-2 — Event Logging | Shared reporting depends on auditability across access and safety controls. | |
| Recommendation — Enforce lifecycle control and revocation for AI credentials and tokens. Log access grants, revocations, and safety events in separate audit trails. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about separating access governance from safety governance. |
| A.8.5 — Secure authentication | AI access ownership includes how identities authenticate to tools and services. | |
| Recommendation — Define distinct access-control ownership and review obligations for AI systems. Assign authentication control ownership for AI access paths and credentials. | ||
Practitioner Guidance
What to prioritise: Write down which team owns each control objective before you formalise the operating model. If a single approval or review step is expected to satisfy both access governance and AI safety, split it into two decisions with separate evidence.
What to verify: Check that every AI access path has an identified owner, revocation path, review cadence, and audit trail, and that every AI safety control has a named testing or monitoring owner. If either side cannot produce its own evidence, the boundary is too vague to be reliable.
Decision rule: If the question is “should this actor be allowed to act?”, treat it as access governance. If the question is “is the system behaving safely under real conditions?”, treat it as assurance. Do not let one team sign off for the other unless the control objective is genuinely the same.
What practitioners underestimate: Shared reporting can hide shared failure. A joint dashboard is useful, but it is not a substitute for separate accountability, because a single team cannot usually tune both privilege decisions and model-safety controls with equal rigour.
Practitioner takeaway: Keep the governance model unified at the reporting layer, but separate at the control layer, so access can be governed as authority and safety can be governed as behaviour.