By NHI Mgmt Group Editorial TeamBased on OneTrust: “Agentic Vs. Agentish AI: What It Means for Third-party Risk Management” (November 18, 2025)

TL;DR: Third-party risk teams are increasingly using AI to accelerate vendor onboarding, monitoring, and control assurance, but most organisations are adopting agentish rather than fully agentic systems because oversight, guardrails, and accountability still matter, according to OneTrust. The practical issue is not whether AI can act, but where human review must remain in the loop.


At a glance

What this is: OneTrust says AI is already reshaping third-party risk work, but the practical model is agentish AI with defined boundaries, not fully autonomous systems.

Why it matters: That distinction matters because risk teams are now deciding where AI can accelerate assessments and monitoring without weakening accountability, evidence quality, or human oversight.


Context

Agentic AI describes systems that can monitor, decide, and act with minimal human input, while agentish AI stays inside explicit boundaries and still expects oversight. In third-party risk, that distinction matters because the programme is built around defensible review, evidence handling, and accountable decisions, not just speed.

OneTrust frames the current gap clearly: organisations want AI to reduce assessment burden, but they cannot let automation outrun governance. For IAM and broader security teams, the same pattern appears whenever an automated system starts operating like a non-human identity without a clear lifecycle, scope, or approval boundary.


Key questions

Q: What is the practical difference between agentic AI and agentish AI in third-party risk?

A: Agentish AI works within defined guardrails and supports humans with tasks such as evidence review, scoring, and reminders. Agentic AI can monitor conditions and act without a prompt, which changes the control model. For third-party risk, the practical difference is not capability alone but whether the system can create risk decisions without immediate human review.

Q: Why does AI automation in vendor oversight still need human approval?

A: Because the control objective is defensibility, not just throughput. Human approval preserves accountability for decisions that affect supplier onboarding, exception handling, and control acceptance. Without that review layer, a machine can scale a bad judgement across many vendors faster than the programme can detect and correct it.

Q: What are the warning signs that AI SOC automation is becoming unsafe?

A: Look for actions taken without a linked case, approvals that happen after execution, investigation summaries that cannot be traced back to source evidence, and workflow changes that only one team member understands. Those signals show the SOC has moved from governed orchestration to opaque automation.

Q: Who is accountable when a third party introduces compliance or AI governance risk?

A: The organisation that engaged the third party remains accountable for many of the resulting obligations, even when the vendor performed the activity. That is why contracts, oversight, and evidence collection must be built into vendor governance from the start, not added after an incident.


Technical breakdown

Agentish AI versus fully agentic systems

Agentish AI can initiate or complete tasks within defined guardrails, such as reading vendor evidence, classifying documents, or triggering reminders. Fully agentic systems go further by monitoring inputs continuously, selecting actions, and executing them without a prompt. That difference is not semantic. It determines whether the system is a bounded assistant or an operational actor that can affect risk decisions at scale. In governance terms, the more autonomy a system has, the more identity-like its behaviour becomes, because it starts to act with persistent authority over data, workflows, and outcomes.

Practical implication: Treat higher-autonomy AI as a governed actor, not as a simple productivity feature.

Why third-party risk workflows are a natural AI use case

Third-party risk work contains repeatable tasks that are well suited to controlled automation, including intake, evidence review, control mapping, and monitoring for supplier incidents. The article’s core point is that these tasks benefit from acceleration, but only when the AI stays inside a narrow operating frame. This is where AI governance intersects with third-party access governance: if an agent can read reports, classify evidence, and recommend outcomes, then its permissions, data lineage, and audit trail become part of the control environment.

Practical implication: Define explicit input sources, permitted actions, and review thresholds before AI touches risk workflows.

Human oversight is the control boundary

The article makes clear that machine scale changes the blast radius of error. An AI system can repeat a bad classification or a faulty recommendation thousands of times before anyone notices, which means oversight cannot be an afterthought. For security and identity teams, that is the same governance problem seen in non-human identities more broadly: access may be valid, but it still needs a lifecycle, logging, and revocation path. Without those controls, speed becomes the risk multiplier.

Practical implication: Place approval, logging, and exception handling at the point where AI action becomes consequential.


NHI Mgmt Group analysis

Agentish AI is the safer default for third-party risk today. The article shows that most risk teams are not yet ready to delegate end-to-end judgement to autonomous systems, because vendor oversight still depends on explainable decisions and accountable review. Agentish AI fits the programme model that most organisations already operate: bounded automation with human approval at the points that matter. Practitioners should see this as a governance design choice, not a temporary compromise.

AI governance and third-party risk are converging into the same operating model. When AI is used to ingest evidence, score vendors, and flag incidents, it stops being a separate innovation project and becomes part of the risk control stack. That creates a governance debt problem if permissions, logging, and decision traceability are not designed together. The practical conclusion is that TPRM teams need shared operating rules with AI governance owners, not parallel processes.

Non-human behaviour creates identity governance pressure even in non-identity programmes. The article is about third-party risk, but the underlying issue is authority delegation. Once an AI system can initiate actions, its access scope, approval boundaries, and offboarding conditions begin to resemble NHI controls. That means IAM and TPRM teams should align on lifecycle governance before autonomy expands beyond clearly bounded use cases.

Agentic ambition will expose weak control design faster than traditional automation ever did. The article’s distinction between automation, generative AI, agentish AI, and true agentic AI is useful because it shows where control failure will occur: at scale, at speed, and across multiple tools. Organisations that cannot explain who approved the action, what data was used, and how exceptions are handled will struggle to defend these systems. Practitioners should govern AI by decision boundary, not by model label.

From our research library:

What this signals

AI governance debt: third-party risk teams that add automation before defining ownership, approvals, and auditability will create faster processes that are harder to defend. The right design question is not how much the model can do, but where its authority must stop.

OneTrust's distinction between agentish and agentic AI maps cleanly to programme maturity. Most teams can use AI to accelerate evidence handling and monitoring now, but they should treat true autonomy as a later-stage operating model that demands stronger control boundaries and lifecycle governance.

52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. That shift matters here because operational ownership is moving closer to the systems that actually enforce permissions and review.


For practitioners

  • Define the AI operating boundary for third-party risk Specify which steps AI may complete autonomously, which require review, and which remain human-only across onboarding, monitoring, and control assurance.
  • Map AI permissions to a lifecycle owner Assign an accountable owner for data access, tool access, approval rights, and offboarding before an agent can touch vendor evidence or risk records.
  • Instrument decision logging and evidence traceability Capture inputs, outputs, exceptions, and reviewer actions so that every AI-assisted recommendation can be reconstructed during audit or incident review.
  • Separate bounded automation from autonomous action Use policy to distinguish repetitive workflow automation from systems that can initiate actions without prompting, then restrict the latter to narrow, high-trust cases.

Key takeaways

  • Agentish AI is the better fit for third-party risk today because it supports bounded automation without surrendering human accountability.
  • The core governance issue is not model capability but decision authority, especially when AI touches vendor onboarding, monitoring, and evidence review.
  • Identity and access controls become relevant as soon as AI systems can initiate actions, because those systems need clear permissions, logging, and offboarding.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article centres on governance boundaries for AI used in risk decisions.
MANAGE — AI Risk ManagementThe article focuses on controlling AI use in operational risk workflows.
Recommendation — Define AI decision ownership, approval limits, and accountability under GOVERN before expanding autonomy. Apply MANAGE to constrain AI use cases to bounded, auditable third-party risk tasks.
ISO/IEC 42001:2023AI management systemThe piece is about operationalising AI oversight within a governance system.
Recommendation — Align AI-enabled risk workflows to an AI management system with clear roles, logs, and review gates.
NIST CSF 2.0GV.RM-01 — Risk Management StrategyThe article is fundamentally about embedding AI into a governed risk strategy.
Recommendation — Update risk strategy so AI-assisted third-party workflows inherit documented oversight and exception handling.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeAI systems need tightly scoped access when they can read, classify, or act on vendor data.
Recommendation — Limit AI-assisted workflow access to the minimum data and tools needed for each task.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementAutonomous or semi-autonomous agents raise the consequence of credential misuse across tools.
Recommendation — Use ATT&CK to map how AI-assisted access could be abused across connected systems.

Key terms

  • Agentish AI: Agentish AI is a bounded AI system that can perform some tasks independently but remains inside clear guardrails. In governance terms, it can automate parts of a workflow without being allowed to make unconstrained decisions or override human approval on high-impact actions.
  • Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
  • Third-party risk management: Third-party risk management is the process of identifying, assessing, monitoring, and reducing risk introduced by external vendors and service providers. In identity terms, it governs who outside the organisation can reach systems or data, how that access is approved, and when it must be removed.
  • AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security teams design lifecycle, access, and oversight controls for systems that act on behalf of people and processes.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org