Treat the AI as a governed non-human operator with least-privilege access, explicit approval rules, and full audit logging. Human engineers should retain incident ownership, while the agent provides analysis and suggested actions. That separation keeps the assistant useful without allowing it to become an unaccountable decision-maker.
What governance has to cover when an AI joins the on-call rotation
The governance question is not whether the AI can help, it is which decisions it may influence versus which decisions remain human-owned. In practice, the safest model is to treat the AI as a bounded operator that can analyze, summarize, and propose actions, while the engineer on call retains approval authority and incident accountability.
That separation matters because on-call work is full of high-context trade-offs. An assistant that can see logs, incidents, and runbooks may speed diagnosis, but it should not be allowed to silently change production state, close incidents, or retry dangerous actions without a defined approval path.
For teams building that operating model, a useful reference is the Agentic AI Security Policy Template, which is oriented around registration, ownership, oversight, tools, and retirement. The core governance pattern is to make the AI’s role explicit enough that every meaningful action can be traced back to a responsible human owner.
How to separate analysis, suggestion, and execution
Security teams should define three different permission bands: read-only analysis, recommended action generation, and approved execution. Most value comes from the first two, because they reduce time-to-understand without expanding blast radius. Execution should be limited to narrow, reversible actions with explicit authorization rules, not broad operational privileges.
This is where least privilege becomes more than a slogan. If the AI can reach paging systems, ticketing systems, cloud consoles, or deployment tools, each connector needs its own scope, TTL, and revocation path. A governance model that works for a chat assistant can fail quickly once the same assistant can touch remediation systems.
Teams evaluating those boundaries often find it useful to review the AI Agent Identity Security Buyer’s Guide because it focuses on identity, access, and PoC criteria for agent tooling. That lens helps clarify whether the assistant is merely observing the incident, or actually acting inside the operational stack.
For environments where the assistant reaches deeper into infrastructure, the AI Infrastructure Workload Identity Guide is a practical reminder that pipelines, notebooks, inference services, and registries all need separately governed identities and credentials. The same principle applies to an on-call AI, because its access should be bounded to the smallest set of systems needed to do useful work.
What good operational control looks like in practice
The right operating model has four visible properties: every assistant action is attributable, every privileged step is approved, every sensitive output is logged, and every boundary can be revoked quickly. Human engineers should remain the incident owners, with the AI functioning as decision support rather than a surrogate responder.
Teams should also be careful about session and credential design. Long-lived secrets, shared tokens, or reusable service credentials make the assistant hard to contain if its context is abused or its prompt surface is manipulated. Short-lived access, scoped connectors, and separate identities per environment are much easier to govern and audit.
That is why the broader NHI governance body of work still matters here, especially the Ultimate Guide to NHIs, which covers lifecycle, visibility, rotation, and offboarding. An AI teammate is a non-human operator, so its access should be managed like a governed identity, not like an informal automation shortcut.
For a policy-oriented view of how those guardrails fit together, the Agentic AI Security Guide is useful because it frames controls around tools, orchestration, and identity. That helps teams translate “AI can assist” into concrete operating limits that are understandable during an incident.
Risk and Threat Considerations
AI teammates create risk when their reach exceeds their judgment. If the assistant can access incident data, operational systems, or response tooling without tight scoping, a prompt injection, poisoned context, or bad recommendation can turn a helpful observer into an amplifier for outage, data exposure, or unauthorized change.
Failure mechanism: The assistant inherits enough trust to influence operational decisions, but it is not reliably capable of human-grade intent checking, escalation judgment, or blast-radius awareness. Attackers and misconfigurations can exploit that gap by steering the model, reusing its access, or inducing it to recommend unsafe actions.
Impact: Teams can lose incident integrity, create false confidence in automated remediation, or hand over privileged actions to an entity that cannot be held accountable in the same way as a human responder. The result is often slower recovery, wider impact, and more difficult post-incident reconstruction.
In agentic environments, the Agentic AI Security Guide helps frame those threats around tool misuse, identity abuse, and cascading failures. For on-call use cases, the critical concern is not the assistant’s intelligence, it is whether its permissions and decision rights can be abused faster than a human can intervene.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI teammate access must be bounded to avoid excessive privilege in on-call workflows. |
| NHI-02 — Secret Leakage | On-call assistants may expose tokens or credentials through logs, prompts, or connected tools. | |
| Recommendation — Scope the assistant to the minimum permissions needed for analysis and tightly review any execution rights. Prevent the assistant from seeing or emitting secrets and enforce redaction in logs and prompts. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI teammates can misuse delegated access if identity and approval boundaries are weak. |
| Recommendation — Bind every agent action to explicit authorization and human ownership for privileged steps. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The assistant should only receive the minimum access needed for on-call analysis and suggestions. |
| AU-2 — Event Logging | On-call AI decisions and actions need auditability for incident review and accountability. | |
| IA-5 — Authenticator Management | Agent access depends on credentials and their lifecycle, especially for tool and system connectors. | |
| Recommendation — Apply least privilege to separate read, recommend, and execute permissions. Log agent prompts, outputs, approvals, and executed actions in a tamper-resistant audit trail. Use short-lived credentials and rotate or revoke them quickly when the assistant’s role changes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | AI teammates should be continuously verified and constrained rather than trusted by default. |
| Recommendation — Continuously validate the assistant’s access context before allowing sensitive actions. | ||
Practitioner Guidance
What to verify: Confirm that the AI can only read the incident context and propose actions unless a specific, reviewed workflow authorizes execution. If it can trigger changes, verify that those changes are reversible, scoped, and separately logged.
Decision rule: If an action can affect customer traffic, data integrity, or privileged access, require human approval before execution. If the action is low-risk and reversible, you can consider narrow automation, but only with clear owner assignment and rollback criteria.
Practitioner takeaway: The safest model is not “human or AI,” it is “human-owned, AI-assisted.” Keep the assistant useful by letting it accelerate analysis, but keep incident authority, accountability, and final approval with the engineer on call.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org