Third Party AI Agent Risk: Security Guide

.

Third party AI agent risk begins when an agent built, hosted, or operated outside your organization can read data, use enterprise tools, or take action on behalf of a person or business process. A vendor assessment may tell you how the provider protects its company. It does not, by itself, tell you whether one of its agents has the right identity, access, authority, or behavioral controls for your environment.

See how Living Security helps security teams predict and prevent third party AI agent risk with human oversight.

What is third-party AI agent risk?

This definition is intentionally narrower than general AI governance and broader than vendor security. The question is not only whether a vendor is trustworthy. The question is whether a specific agent can operate safely inside a specific business context.

A useful governance boundary has four parts:

• Identity: Can you distinguish the agent from the human who initiated a task, the vendor that supplied it, and other agents?
• Access: Which systems, records, tools, and data classifications can it reach?
• Authority: Can it recommend, prepare, approve, or execute a consequential action?
• Evidence: Can you reconstruct what it saw, why it acted, what it changed, and who was accountable?

NIST's concept paper on software and AI agent identity and authorization highlights identification, authorization, access delegation, logging, and non-repudiation as central questions. Those questions give security teams a practical starting point for governing agents that cross organizational trust boundaries.

Why is a vendor assessment not enough?

Traditional third-party risk management usually evaluates the supplier. It reviews security controls, privacy practices, resilience, compliance evidence, and contractual obligations. Those controls still matter. They answer whether the provider has a credible security program.

Third-party AI agent risk adds an operational layer. An approved provider may offer several agents with different models, tools, data paths, and levels of autonomy. One may summarize approved records. Another may update tickets, change access, or send messages. Treating both as the same vendor risk creates a governance blind spot.

Security teams should separate three decisions that are often combined:

1. Should we trust this provider? Review the provider's security, privacy, resilience, and support obligations.
2. Should we trust this agent in this use case? Confirm its purpose, data scope, tools, autonomy, and failure behavior.
3. Should we trust this action right now? Evaluate the current identity, behavior, threat context, and business impact before allowing execution.

This separation prevents a vendor approval from becoming a blanket authorization. It also gives procurement, security, identity, legal, and business owners a common decision model. The provider owns its service. Your organization owns the conditions under which that service can operate in your environment.

How should security teams assign ownership?

Every production agent should have a named business owner and a named technical owner. The business owner defines the intended outcome and accepts the operational risk. The technical owner maintains the integration, identity, permissions, monitoring, and retirement process. A vendor contact can support both owners, but should not replace them.

Create an agent record before granting access. At minimum, record:

• Agent name, provider, version, environment, and deployment location.
• Business purpose and approved use cases.
• Human owner, technical owner, and escalation contact.
• Systems, tools, data classes, and regions in scope.
• Allowed actions, prohibited actions, and approval thresholds.
• Delegation chain, credentials, token lifetime, and authentication method.
• Expected behavior, monitoring sources, review frequency, and retirement trigger.

Ownership must survive personnel changes and vendor changes. If the original sponsor leaves, the agent should not remain active by default. A lifecycle review should confirm that the business purpose still exists, the permissions remain necessary, and the evidence needed for investigation is still available.

Living Security's AI agent identity security guide covers the identity, delegation, authorization, runtime assurance, and termination layers that make this lifecycle concrete. For third-party agents, add a provider boundary to the record. The organization should know which controls are enforced by its own systems and which are only promised by the vendor.

Which access controls reduce third-party AI agent risk?

Start with least privilege, then add least agency. Least privilege limits what an agent can reach. Least agency limits what it can do without approval. An agent that needs to recommend a remediation does not automatically need permission to apply it.

Use a control design that matches the agent's capability and potential impact:

Do not let a third-party agent inherit the full privileges of the person or service that connected it. Use purpose-limited credentials, short-lived tokens where supported, separate identities for separate agents, and explicit boundaries between development, test, and production. Revoke access when the use case ends, the provider changes material behavior, or monitoring shows unexplained activity.

OWASP's agentic AI threats and mitigations guidance describes risks such as confused deputy behavior, identity spoofing, non-human identity exposure, and overreliance on human-in-the-loop controls. These risks reinforce a simple rule: approval is not a substitute for technical boundaries.

What behavior signals should teams monitor?

Access reviews tell you what an agent is allowed to do. Behavior signals tell you what it is actually doing. Monitoring should compare observed activity with the agent's approved purpose, normal operating pattern, delegated authority, and current threat context.

Useful behavior signals include:

• New tools, systems, data sources, or destinations used by the agent.
• Requests outside the agent's declared business purpose.
• Unusual volume, timing, sequence, or repetition of actions.
• Repeated denied requests, approval failures, or attempts to bypass controls.
• Unexpected delegation to another agent, plugin, connector, or identity.
• Changes in prompts, configuration, model version, or provider behavior.
• Actions that differ from the initiating user's normal work pattern.

Behavior should not be assessed in isolation. A large export may be normal for a reporting agent and dangerous for a ticket triage agent. The same API call may be low impact for a public record and high impact for a privileged identity store. Context turns raw activity into a useful risk signal.

Living Security's Human Risk Management approach correlates behavior, identity and access, and threat signals. That model is useful for third-party agents because an agent with ordinary behavior may still create significant exposure if it has privileged access or is operating during an active attack. Conversely, an unusual action may be low risk when it is authorized, explainable, and isolated.

How should threat context change agent decisions?

Third-party AI agent risk changes with the environment around the agent. A provider may be operating as designed while an attacker is attempting prompt injection, stealing credentials, abusing a connected account, or manipulating the data the agent consumes. Governance must therefore evaluate the agent and the surrounding threat context together.

Threat-aware controls should answer:

• Is the agent accessing a system or identity currently associated with an investigation?
• Has the provider, model, connector, or dependency changed recently?
• Are there signs of credential theft, unusual delegation, or data movement?
• Does the requested action affect a high-impact asset, privileged account, or regulated data?
• Should the agent pause, reduce scope, request approval, or continue?

This is where static allowlists fall short. An allowlist may confirm that an agent can call a system. It does not determine whether the call is appropriate at this moment. Runtime decisions should combine identity, behavior, asset impact, and threat intelligence before the agent is permitted to proceed.

NIST's AI Risk Management Framework organizes AI risk work around govern, map, measure, and manage. Applied to third-party agents, those functions create a continuous cycle: define accountable governance, map the agent and its dependencies, measure activity and impact, then manage risk through controls and intervention.

What should human oversight look like?

Human oversight should be deliberate, risk-based, and supported by evidence. Asking a person to approve every low-impact action creates alert fatigue. Allowing an agent to execute every high-impact action creates unacceptable exposure. The right model assigns review where human judgment adds the most value.

Use graduated autonomy:

1. Low impact: permit routine actions within a narrow scope, with monitoring and periodic review.
2. Moderate impact: require a confidence threshold, policy check, or sampled human review before execution.
3. High impact: require explicit human approval, dual control, or a separate change process.
4. Unclear or anomalous: pause the agent, preserve evidence, reduce access, and escalate to the owner.

Human oversight must also include the ability to say no. Reviewers need enough context to understand the request, the agent's reasoning, the affected systems, the evidence supporting the action, and the consequence of approval. They also need a practical pause or revoke mechanism that works when the agent is moving quickly.

Measure oversight quality, not only approval volume. Track how often reviewers reject or modify recommendations, how long high-impact actions remain pending, whether alerts are concentrated in one agent or provider, and whether incidents reveal missing context. These measures show whether governance is improving decisions or merely adding clicks.

A practical operating model for third-party AI agents

Security teams can operationalize third-party AI agent risk with a repeatable five-stage process:

1. Discover: identify agents in approved applications, marketplaces, integrations, scripts, and business workflows. Include shadow agents discovered through identity, API, and data activity.
2. Register: assign owners, purpose, provider, systems, data scope, autonomy tier, and retirement conditions.
3. Constrain: apply least privilege, least agency, purpose-limited credentials, approval gates, rate limits, and environment boundaries.
4. Observe: correlate behavior, identity and access, and threat signals. Compare actual activity with the approved operating model.
5. Intervene: guide, pause, restrict, revoke, or retire the agent when risk changes. Preserve the evidence needed to explain the decision.

This model is intentionally continuous. A vendor review at onboarding is a starting point, not a permanent trust decision. Reassess when an agent gains a new tool, changes its model or workflow, moves into production, handles more sensitive data, or begins acting outside its expected pattern.

For organizations building a broader workforce risk program, Living Security's governance model for humans and agents provides a useful bridge between human identity governance and non-human identity governance. The goal is not to treat people and agents as identical. It is to apply consistent accountability, access, observability, and intervention principles to every identity that can affect enterprise risk.

Build a more complete view of third-party AI agent risk with Living Security's AI-native Human Risk Management platform.

Frequently Asked Questions

What is the difference between third-party risk and third-party AI agent risk?

Third-party risk evaluates the supplier and the relationship. Third-party AI agent risk evaluates the specific agent's identity, access, authority, behavior, and impact inside your environment. Both layers matter, but a supplier approval should not grant every agent unrestricted authority.

Should every third-party AI agent require human approval?

No. Human approval should match the action's potential impact and uncertainty. Low-impact, well-bounded actions may run with monitoring. High-impact or anomalous actions should require explicit approval, stronger controls, or a pause.

Which teams own third-party AI agent risk?

Ownership is shared. Security sets risk and monitoring expectations, identity teams manage authentication and authorization, procurement and legal govern the provider relationship, and the business owner accepts the use-case risk. One named owner should remain accountable for the agent's lifecycle.

How can security teams detect unmanaged third-party AI agents?

Compare approved agent records with identity activity, API calls, application integrations, data access, and unusual delegation patterns. Agents that appear in production activity without an owner, purpose, or documented access scope should enter an investigation and registration workflow.

Third-party AI agent risk is manageable when organizations govern the conditions of action, not just the reputation of the provider. Clear ownership, scoped identity, least agency, behavior signals, threat context, and human oversight give security teams a way to enable useful agents while keeping consequential decisions accountable.

Further reading: OWASP agentic AI threats and mitigations and NIST software and AI agent identity and authorization concept paper.