Workday AI Security: Tenant Controls and the Integration Boundary

Workday's current AI pages lead with Sana, Sana AI agents from Workday, and Agent System of Record. The mechanism is inside an enterprise SaaS boundary: Workday identities and business-process security govern tenant access, while encryption protects stored and transmitted data. Supported activity is recorded in Workday's audit tools. Workday's responsible-AI process reviews system risk. A customer-built integration that sends data to an external LLM creates another boundary. I want to separate embedded Workday AI from that configurable HTTP path because each one supports a different control claim.

TL;DR

• Current Workday AI security reviews should use Sana and Agent System of Record terminology for the relevant current offerings.
• Workday documents role-based security with SAML SSO; certificate authentication with OIDC; encryption with BYOK; and tenant audit trails with activity reports.
• Responsible-AI review and customer-data commitments belong to Workday's product and vendor boundary.
• An external gateway governs only customer-controlled AI HTTP requests explicitly routed through it with caller and policy context.

Sana is inside the Workday application boundary

Workday's current artificial intelligence page describes Sana as built on Workday data and integrated with business applications. It presents a system for customers to build and orchestrate agents, then manage them across business functions. The related Sana AI agents page organizes agents around HR, Finance, IT, and Legal work.

An embedded Sana interaction is inside Workday-operated interfaces, tenant controls, and vendor-managed services. A customer may lack a configurable network hop where an external gateway can inspect the prompt. That positioning matters for a security diagram because the review should identify the exact agent and Workday tenant, along with the connected business process, data objects, and any external applications the agent reaches.

Using "Workday AI" as one large box hides too much. I would force the diagram to show each agent and integration separately, even if the first version needs six sticky notes across a conference-room wall. The complexity is real. It reflects control ownership.

Tenant identity and business roles gate application access

Workday's security overview documents role-based security and SAML SSO. Certificate authentication covers user and web-service integrations, and the page also describes OpenID Connect support. These mechanisms establish identities at the Workday boundary. They cover humans and integrations.

A production test should use named synthetic workers and tightly scoped service identities. Give one test user access to a fictional compensation record. Deny a second user access. Run the same approved business process under both accounts. For a web-service integration, preserve the certificate identity and the Workday security group or domain permissions applied to it. Then revoke the credential and retest.

Workday tenant permissions are authoritative for Workday records and processes. For an integration acting for several upstream users, a valid service certificate may be its identity. If that integration later sends an AI request to an external model, it must propagate the initiating identity and purpose when policy depends on them. The post-authentication gap is present when every upstream user collapses into one technical credential.

Encryption and BYOK protect stored and transmitted data

Workday says customer data at rest is encrypted using AES with a 256-bit key and that TLS protects internet access. The security page also describes an optional bring-your-own-key capability that gives customers control of root encryption keys. Those properties are part of vendor due diligence and the tenant's cryptographic-control inventory.

Evidence should identify the Workday service and tenant covered, along with the enabled key arrangement and key owners. It should also identify the recovery process and rotation procedure. A TLS test can establish the expected hostname and certificate path. BYOK procedures should be exercised in a non-production tenant under the applicable Workday guidance and contract.

Encryption protects content in storage. It also protects content in transit. Authorized processing at the application or model endpoint can still see that content. A compensation-planning integration may hold legitimate Workday access and use encrypted transport while sending a prompt that violates an internal rule for external model use. Data classification and destination policy have to run where that configurable HTTP request can be inspected before forwarding.

Audit evidence reconstructs tenant activity

Workday's security page describes tenant audit trails and user-activity logs, along with sign-on reports and historical visibility into transactions and configuration changes. These records help an investigator establish access and administrative state inside Workday. Collection procedures should specify the report, filters, timezone, and retention. They should also specify the owner and export destination for the customer's tenant.

Run a quarterly evidence drill around one synthetic personnel change. Preserve sign-on evidence, the business transaction, any security-group change, and the configuration history. Confirm that the actor and integration identities resolve cleanly. Record the query parameters and extraction time beside the export.

A Workday activity record proves the supported tenant event represented in that report. A customer integration's external model call can require another record containing prompt classification and the policy decision made before transmission. AI audit-log schema design provides the useful join fields: principal and relay; route and policy version; outcome and timestamp; and correlation ID. Keep both evidence sources intact. Do not flatten them into one generic "AI log."

Responsible AI governs the Workday product process

Workday's responsible AI page says its risk-based review evaluates susceptibility to unintended consequences and how identified risks should be managed. Workday also says safety and security are part of development through deployment. The vendor states that it does not share customer data to train third-party public models and describes transparency with privacy commitments, human-centered design with fairness, and customer data control as principles.

Those statements support a review of the Workday-operated AI capability. Ask which exact Sana agent or AI capability the available documentation covers, including its intended use and data access. The documentation should also cover human oversight and customer configuration. Procurement should map the statements to the applicable agreement and service.

Customer-built integrations retain their own obligations. The team selecting an external model must assess that provider and define permitted data classes. Application owners must propagate identity and purpose. Security owns the request policy on the configurable route. Legal and privacy teams set use constraints.

The integration diagram decides gateway coverage

Draw two distinct traffic paths on the review diagram. The first is within a Workday-operated Sana experience. Workday tenant controls and vendor practices govern that path, with customer configuration inside the product. The second is a customer integration sending an HTTP request toward an external LLM endpoint. Only the second path can cross an independent gateway when the organization controls routing.

At the gateway, policy can evaluate the application-supplied caller or agent and role, along with business purpose and prompt classification. It can also evaluate the destination model and operation under the applicable policy version. Policy forwards a permitted request toward the selected external model. Another request can be blocked or redacted before transmission. The resulting decision record should retain a correlation value that links back to Workday and integration telemetry.

The AI gateway architecture gives platform teams a pattern for that configurable path. It cannot create visibility into embedded Sana interactions that are entirely inside Workday. Workday roles and SSO, encryption and BYOK, audit reports and retention, and responsible-AI review are also in place. Accurate coverage begins with the route, rather than the vendor logo on the diagram.

DeepInspect

This is the gap DeepInspect closes for customer-controlled integrations that route AI HTTP traffic through its boundary. DeepInspect evaluates application-supplied identity and role alongside business purpose and prompt classification. It also evaluates the model destination and operation under the versioned policy before permitted traffic reaches the external LLM.

Workday is still the governing boundary for its tenant and business processes, stored data and embedded Sana capabilities, identity controls and encryption, and supported audit evidence. DeepInspect independently allows or blocks traffic. It can redact content and creates a signed, tamper-evident record only for the configurable request path it inspects. Book a technical deep dive at deepinspect.ai.