Agentic vs agentish AI: what risk teams need to know

At a glance

What this is: OneTrust argues that agentish AI fits today’s third-party risk environment better than fully autonomous agentic systems because it preserves human oversight while improving assessment, monitoring, and reporting speed.

Why it matters: For IAM, IGA, and NHI programmes, the distinction matters because AI tools that assess vendors, process evidence, or act across systems can inherit access, data, and accountability risks that need explicit governance.

By the numbers:

• In 2024, AI-related incidents grew more than twenty-six times over the previous three years.
• 95% percent of enterprise generative AI projects had not met their expected return on investment.

👉 Read OneTrust's analysis of agentic vs agentish AI for third-party risk management

Context

Agentic AI is moving faster than most governance models, but the practical question for risk teams is whether a system should act independently or remain bounded by human review and policy. In third-party risk management, that distinction affects onboarding, monitoring, evidence review, and accountability, especially when AI systems can touch vendor data, control artefacts, and workflow decisions.

The article’s core point is that agentish AI, not full autonomy, is the workable near-term model for most organisations. That has a clear identity and access management intersection because any AI system that reads assessments, moves evidence, or issues workflow actions needs scoped permissions, auditability, and lifecycle control just like other non-human identities.

Key questions

Q: How should security teams use AI in third-party risk management without over-automating decisions?

A: Use AI to continuously prioritise vendors, detect anomalies, and flag contract or control drift, but keep approval, exception handling, and accountability with humans. The practical goal is faster triage, not delegated trust. AI should shorten the path to review, while IAM and governance teams still own the access and renewal decision.

Q: Why do access sprawl and AI workflows create more identity risk?

A: Because they multiply the number of places where credentials, approvals, and delegated actions can occur without clear ownership. AI-assisted workflows can accelerate access requests and routing, but governance often remains designed for slower human processes. That mismatch creates gaps in review, revocation, and accountability.

Q: What breaks when AI agents have broader access than their tasks require?

A: Over-privileged agents break segregation of duties, weaken auditability, and expand blast radius across transactions, data lookups, and workflow triggers. In banking, a single agent identity can act with more operational reach than any human reviewer can safely justify.

Q: Who is accountable when an AI system makes a harmful decision?

A: Accountability should follow the identity chain that authorized, configured, or triggered the action, including the human owner, the platform team, and any delegated agent or tool account. If the organisation cannot name that chain, the governance model is too weak for regulated AI use.

Technical breakdown

Agentish AI vs agentic AI in third-party risk workflows

Agentish AI describes bounded systems that can initiate or complete tasks inside defined guardrails, while agentic AI describes systems that observe, decide, and act with broad autonomy. In third-party risk management, the difference is not semantic. A bounded system can score inherent risk, route reminders, and classify evidence, but it should not independently change controls or approve high-risk suppliers without review. The control problem is therefore not model capability alone, but the scope of delegated authority, the data it can reach, and the approvals that must still exist around it.

Practical implication: define explicit action boundaries before allowing any AI workflow to touch vendor risk decisions.

AI governance, access management, and audit logging

Once AI starts operating in risk workflows, it behaves like a non-human identity from a governance perspective. It needs a distinct identity, least-privilege access, traceable actions, and revocation paths when the workflow ends or the model changes. Audit logging matters because a risk system that assembles evidence or correlates findings must be explainable after the fact, not just efficient in the moment. That is where access management and data lineage become governance controls rather than administrative extras.

Practical implication: treat AI workflow accounts as governed identities with least privilege, logging, and offboarding.

Why automation scale changes control assurance

Automation compresses time, and that is the hidden governance challenge. A human analyst may review a handful of exceptions, but an AI agent can process hundreds of vendor records, identify patterns, and trigger actions before the organisation has validated whether the underlying logic is safe. This creates a scale problem for oversight, because errors no longer stay isolated. They multiply across the pipeline, especially if the system consumes incomplete evidence or is allowed to overstep its intended scope.

Practical implication: test AI control workflows for blast radius, not just accuracy.

Threat narrative

Attacker objective: The attacker or failure mode is to exploit over-delegated AI workflow authority so that trust, access, and decisions scale faster than human oversight can contain.

1. Entry occurs when an AI-enabled risk workflow gains access to vendor data, assessment artefacts, or workflow systems beyond a narrow task boundary.
2. Escalation follows when the system is allowed to make or trigger decisions that should remain human-approved, such as risk scoring, remediation routing, or approval triage.
3. Impact emerges when scale and speed propagate a flawed decision across many vendor assessments, creating governance errors, missed risk, or uncontrolled access to sensitive data.

NHI Mgmt Group analysis

Agentish AI is the governance shape most enterprises actually need. Fully autonomous systems create decision speed that outstrips current risk governance, while bounded systems preserve reviewable accountability. In third-party risk, that matters because assessments, evidence collection, and supplier scoring are governance decisions, not just automation tasks. The practical conclusion is that risk teams should design for constrained delegation rather than autonomy-first deployment.

AI systems used in risk workflows become non-human identities once they can access data and trigger actions. That means the same questions apply as in NHI governance: who owns the identity, what can it reach, how is it monitored, and how is it retired. When those answers are vague, the organisation has created an unmanaged control plane for decisions. The practitioner takeaway is to bring AI workflow accounts into identity governance, not leave them in a tooling exception.

AI governance debt builds when scale is treated as success before control quality is proven. The article’s emphasis on speed, visibility, and efficiency is valid, but these gains only matter if the underlying evidence, access, and approval models remain defensible. Otherwise, teams merely automate inconsistency at higher volume. Practitioners should measure control quality before they scale task volume.

Third-party risk is becoming an identity problem as much as a process problem. When AI tools read vendor artefacts, ingest external trust data, or trigger follow-up actions, they inherit access boundaries and offboarding requirements. That creates a named governance gap: delegated workflow authority without lifecycle control. The field should treat that gap as a first-order risk, not a future edge case.

Regulatory pressure will increasingly target explainability, ownership, and traceability rather than the label of the AI system. The distinction between agentic and agentish matters because regulators and auditors will care about whether decisions can be attributed and constrained. Risk teams that can show clear ownership, logging, and review thresholds will be better positioned than teams that only document model capabilities. The practitioner conclusion is to make accountability visible at design time.

What this signals

Delegated workflow authority is the next governance pressure point. As AI tools move from analysis support into action support, identity teams will need to decide whether each workflow has a distinct identity, an owner, and a revocation path. That is a control design problem, not a tooling preference, and it should be assessed alongside access review and secret management.

The operational signal for practitioners is that AI adoption in third-party risk will increasingly depend on proving control quality, not just processing speed. If the workflow cannot show who approved the action, what data it used, and how it can be shut off, it should not be allowed to operate beyond recommendation mode.

Non-human identity governance now has to include AI-enabled business workflows. The governance model that works for service accounts, API keys, and automation scripts is becoming the baseline for AI assistants that touch vendor data. Teams that already align to the OWASP NHI Top 10 will be better positioned to extend those controls to AI workflow identities without inventing a new exception path.

For practitioners

• Define AI decision boundaries Specify which third-party risk tasks an AI system may complete, which ones it may only recommend, and which remain human-approved. Document those boundaries in workflow design and access policy before production use.
• Assign each AI workflow an identity Create separate accounts or service identities for AI workflows, with least privilege, logging, and lifecycle ownership. Revoke access when the workflow changes, the model is retired, or the vendor relationship ends.
• Review control evidence for automation drift Check whether AI-generated assessments, classifications, or reminders are changing the meaning of the evidence you rely on. Pair sampled human review with audit trails so you can prove that the workflow still matches policy intent.
• Map AI workflow access to NHI governance Bring AI-enabled risk tools into the same governance process used for other non-human identities, including access review, secret management, and offboarding. Use the Ultimate Guide to NHIs and OWASP NHI Top 10 to align the operating model.
• Set scale thresholds for intervention Define the point at which AI-assisted vendor monitoring, scoring, or evidence classification must pause for human validation. This prevents one flawed model decision from propagating across the full supplier base.

Key takeaways

• Agentish AI is the practical governance model for third-party risk because it preserves reviewable accountability while limiting delegated authority.
• When AI systems can read evidence, route tasks, and trigger decisions, they start to behave like governed non-human identities and need lifecycle controls.
• AI adoption in risk programs should be measured by control quality, auditability, and blast radius reduction, not just throughput gains.

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: Agentic AI is a system that can observe conditions, decide what to do next, and execute actions with broad autonomy. For security teams, the important issue is not the label but the level of delegated authority, the data it can reach, and the controls around its actions.
• Delegated Workflow Authority: Delegated workflow authority is the permission a system receives to act on behalf of people or teams inside a business process. In AI governance, it becomes risky when the system can move from recommendation into execution without clear ownership, logging, and revocation paths.
• Non-Human Identity: A non-human identity is any machine or software identity that authenticates to systems, such as service accounts, API keys, tokens, certificates, bots, workloads, or AI agents. These identities need lifecycle governance because they can access data and perform actions without being tied to a human user.

What's in the full article

OneTrust's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of how agentish AI can automate supplier onboarding without taking over approval authority.
• Practical comparisons between automation, generative AI, agentish AI, and fully agentic systems in third-party risk workflows.
• Vendor-side examples of how AI can assemble assessments, correlate incidents, and classify evidence at scale.
• The article's framing on where risk, compliance, and workflow ownership need to sit when AI supports third-party oversight.

👉 OneTrust's full blog expands the practical differences between bounded AI workflows, autonomy, and third-party risk controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, machine identity security, and secrets management. It gives practitioners a common control language for governing AI workflows, service accounts, and other non-human identities across the enterprise.