Reviewing UiPath Agentic Automation — what the AI Trust Layer certifies, and what it doesn't

Certification against a management-systems standard like ISO 42001 verifies that a governance process exists and is followed — it is not a penetration test result, and it does not certify that every customer's specific deployment is configured safely. That distinction is the same one that applies to any ISO or SOC 2 certification: it says the vendor has a process; it says nothing about whether a given customer used that process correctly.

Read literally, these certifications cover platform-level governance: that UiPath has documented processes for AI risk management, that policy evaluation mechanisms exist and are applied, that data-handling commitments (like not retaining customer data for third-party model training) are backed by an audited process rather than a marketing claim. That's meaningfully more assurance than a platform with no third-party attestation at all.

What it doesn't certify is any individual customer's configuration — which agents were granted which credentials, which automations run unattended against production systems, and whether a specific deployment's policy settings are actually tight. A platform can be well-governed and a specific tenant's use of it can still be misconfigured.

RPA credentials were built for a world where a bot followed a fixed script. Agentic automation gives an AI agent judgment over which of those same broad credentials to use, and when — the blast radius didn't shrink when the automation got smarter.

UiPath's RPA heritage means a lot of existing deployments already hold broad, standing credentials into ERP, HR, and finance systems — that's what RPA bots have always needed to click through legacy interfaces. Layering an agent on top that now decides which automation to trigger, rather than executing a fixed script, means an agent's judgment error can now reach whatever that standing credential could always reach. The AI Trust Layer's policy evaluation is the control meant to bound that — a review has to confirm it's actually configured to bound it for the specific credentials and systems in play, not assume the platform-level certification already did that work.

UiPath's documented AI Trust Layer architecture is more specific than “policy evaluation exists”: it applies as “Policy-as-Code” consistently across agents built on Azure, Bedrock, LangChain, or UiPath itself — meaning it's meant to govern third-party model and agent frameworks brought into the platform, not only UiPath-native ones. It operates at three distinct layers: Agent level (validating an agent's own prompt and system instructions before execution), LLM level (monitoring request and response traffic to the model), and Tool level (validating tool inputs and outputs during task execution). One concrete operational detail worth knowing: policy changes propagate through a five-minute cache, so a guardrail update isn't live instantly — relevant if a review is timing an incident response around when a policy change actually takes effect.

Credential handling has its own documented topology. Orchestrator supports pluggable credential stores (Azure Key Vault, HashiCorp Vault, Thycotic Secret Server, BeyondTrust, AWS Secrets Manager, CyberArk, or a custom plugin) through two proxy modes: Connected Proxy, where Orchestrator retrieves credentials from the vault and passes them to the robot, and Disconnected Proxy, where the robot retrieves credentials directly from the vault, bypassing Orchestrator's mediation entirely. That second mode removes Orchestrator as an audit point for credential access — worth flagging explicitly for any deployment using it. Unattended robots separately authenticate to Orchestrator via OAuth 2.0 client credentials and need their own Windows login credentials to actually run automations, meaning two distinct credential surfaces exist per robot, not one.

For any team running UiPath Agentic Automation, a design-time review should be able to answer:

• Are agent-directed automations using the same broad, standing RPA credentials as legacy scripted bots, or have credentials been scoped down to what the agent's actual task requires?
• Is AI Trust Layer policy evaluation actually configured for the specific systems (ERP, HR, finance) an agent's automations can reach, or left at platform defaults?
• Which agent-triggered automations require human approval before executing against a production system, versus running unattended?
• Has the specific tenant configuration been reviewed against the ISO 42001 / AIUC-1 governance process UiPath documents, rather than assuming the certification alone covers it?
• If Disconnected Proxy is used for any credential store, is there a compensating audit mechanism given Orchestrator no longer mediates that credential access?
• Does the incident-response plan account for the AI Trust Layer's 5-minute policy-propagation delay, rather than assuming policy changes take effect immediately?

See tool-use permission scoping for the general pattern behind the credential-scoping question above.