Search security

NL Search changes how users ask, not what they can find. Every search runs in PeopleSoft, through the Search Framework, as the signed-in user, with the same security as any other PeopleSoft search.

PeopleSoft’s search security

Each search definition has one of three security settings, set on its Security page:

• No security makes the definition’s documents searchable by anyone who can use PeopleSoft.
• Source-level security decides who can search the definition at all. Only the users and roles you grant it to get results from it, whatever they ask.
• Document-level security decides which documents each user sees. One or more of the search definition’s query columns act as security attributes, often columns that users never search on, such as a department or business unit. When the user searches, the search definition’s document filter application class returns the attribute values that this user may see, and PeopleSoft returns only documents with those values.

For example, if the voucher index’s security attribute is BUSINESS_UNIT, and the application class returns US001 and US002 for a user, that user’s searches find only vouchers in those two business units, whatever they ask.

Why NL Search can’t widen access

• PeopleSoft runs the search. The plan is run by the Search Framework, as the user, so the search definition’s security applies, exactly as it does in PeopleSoft’s own search pages.
• Security isn’t part of the plan. PeopleSoft adds its security filters itself. A plan has no way to express them, so no question can remove them.
• Plans are limited to the Intent Store. A plan can only name an intent’s category and fields, and only with their allowed operators. The service rejects anything else, so no plan can reach another index, or filter on an attribute you haven’t chosen to expose.
• The service can’t search. The NL Search Service has no access to PeopleSoft or OpenSearch at all. It returns a plan, and nothing more. Only PeopleSoft queries the indexes, so keep the OpenSearch servers reachable only from PeopleSoft and its administrators.

It can’t narrow access either

NL Search applies exactly the security PeopleSoft already has. If a search definition has no security, everyone who uses NL Search can find everything it indexes, as they already could with Global Search. Before you add an intent, check the security of the search definitions behind its category.

What the LLM sees

The LLM sees the question, today’s date, the user’s language, and the candidate intents. It never sees search results, or the user’s identity. Even for a question such as “my open requisitions”, the plan says only me, and PeopleSoft fills in who that is.

The question itself can contain personal data, such as a name in “expense reports for Pat Lee”, and it’s sent to your LLM provider like any prompt. Use a provider, and terms, that your organization has approved for that.

Prompt injection

NL Search’s LLM reads only the user’s own question and your intents. It never reads text that someone else wrote, such as document contents, so there’s nowhere for another person to plant instructions. A user who writes instructions into their own question can at most get an odd plan for their own search, and validation limits that plan to searches they could run anyway.

That makes NL Search a much smaller target than an assistant whose tools return other people’s text; compare the Assistant’s prompt injection risks.

Between PeopleSoft and the service

• The service accepts requests only from PeopleSoft, over HTTPS, on a connection that authenticates PeopleSoft, such as one with a client certificate.
• The service keeps nothing after it returns a plan, except its audit entry.
• The LLM credentials stay in the service. PeopleSoft never holds them.

The audit logs

The NL Search Service never learns who asked, so its log has no user IDs: each entry records a request ID, the question, the Intent Store and prompt versions, the candidate intents, the plan, whether it passed validation, and whether the search fell back to keywords. PeopleSoft’s application class logs the same request ID with the user who searched, so an authorized administrator can join the two when needed.