Acting as the user

The Assistant can never show more than the user could see on their own, because every PeopleSoft call it makes carries the user’s own identity. There’s no service account with broad access to fall back on, so PeopleSoft’s own security decides what each answer can include.

How identity flows

1. The user opens the chat page, which signs them in to the Assistant with your identity provider. They’re already signed in there, because PeopleSoft uses the same provider for single sign-on, so this normally happens without a prompt. The chat page gets an access token issued for the Assistant service.

2. Every request to the service carries that token. The service accepts only tokens that your identity provider issued for it.

3. When a tool runs, the service exchanges the token for a new one, issued by the identity provider for PeopleSoft, for the same user. It uses the provider’s token exchange: the OAuth 2.0 Token Exchange standard (RFC 8693) or, with Microsoft Entra ID, the on-behalf-of flow.

4. PeopleSoft validates the new token. It checks the signature against your identity provider’s published keys, and the token’s issuer, audience, and expiry. It then maps the token to a PeopleSoft user ID, and runs the API as that user.

The service doesn’t simply forward the chat page’s token to PeopleSoft. A token is issued for one audience, and each service accepts only tokens meant for it, so a token that leaks from one place can’t be replayed at the other.

Set up PeopleSoft to accept the tokens

Since PeopleTools 8.58, PeopleSoft can accept OAuth 2.0 access tokens for its REST services. Which identity providers it can trust depends on your PeopleTools release, so check Oracle’s documentation for yours. The setup has four parts:

1. Register PeopleSoft with your identity provider as an API, and allow the Assistant service to exchange tokens for it.
2. Create a resource-only service application in PeopleSoft, at PeopleTools > Security > OAuth2 Administration > Create OAuth2 Service Apps, and add the OAuth 2.0 settings that the REST listening connector uses to validate tokens to integration.properties.
3. Map tokens to users. Choose the token claim that identifies the PeopleSoft user, such as the user’s sign-in name, and make sure it matches their PeopleSoft user ID or can be mapped to it.
4. Require OAuth 2.0 on the Assistant’s operations. An application service can set the authentication it requires for each URI and method.

The exact fields vary with your PeopleTools release and identity provider. Oracle’s Service Application - REST Provider documentation covers them for PeopleTools 8.63.

What PeopleSoft checks

• Permission lists decide which application services a user can call. You grant them per service, or per root resource within a service, to the roles that should use each tool.
• Row-level security is applied inside each API. PeopleSoft doesn’t add it to an application class’s SQL automatically, so an API that returns other people’s data, such as a manager’s view of their team, must select through the same security views that PeopleSoft’s own pages use, keyed by the current user.

What the Assistant never has

• No PeopleSoft password, and no service account.
• No database connection. Everything goes through the APIs.
• No lasting tokens. Tokens are kept in memory only until they expire, and never written to disk or to the audit log.
• No way to change data. Every tool is a GET operation; see the tool catalog.

Prompt injection

The Assistant reads text that other people wrote, such as comments on a requisition or a supplier’s name, and that text could contain instructions aimed at the LLM. The design limits what such instructions can achieve:

• The tools are read-only and scoped to the user, so injected instructions can at most read more of the user’s own data, or make an answer misleading.
• Answers go only to the user who asked.
• Links stay inside PeopleSoft. The chat page makes links only to your PeopleSoft hosts, and never loads images from answers, so an answer can’t carry data anywhere else.
• Hidden text is removed. The service removes invisible characters from tool results, as the AI Assist server does.

The AI Assist prompt injection page explains the attack in more detail; the same principles apply here.

The audit log

The service records each turn under the user’s identity: the question, each tool call with its arguments and PeopleSoft’s response status, and how long each step took. It doesn’t record the data the tools returned, which stays with the conversation until it expires.

What users see is what PeopleSoft allows

To check the Assistant’s access for a role, sign in as a test user with that role and ask the same questions. The Assistant’s answers can only contain what that user’s APIs return.