Skip to content
SparkyaiPeopleSoft

Security model

AI Assist gives an LLM read access to your PeopleSoft database. That access is what makes its answers accurate, and it’s also why security is built into every layer of the server rather than added on top. This section describes what AI Assist protects, which parts of the system are trusted with what, and the controls at each layer. It’s written for the developers who use AI Assist, and for the administrators and security teams who approve it.

What needs protecting

Section titled “What needs protecting”
  • PeopleSoft data. Application tables hold personal and financial data, such as national IDs, pay, and bank accounts. Only run_select reads them, and only the tables you allow.
  • Definitions and code. Your records, PeopleCode, and SQL are your intellectual property. Code sometimes also holds things it shouldn’t, such as hard-coded passwords.
  • The database itself. A tool that locked rows or ran expensive queries could slow down or block PeopleSoft for everyone.
  • Credentials. The server’s database password and, on a shared server, your developers’ access tokens.

Where data goes

Section titled “Where data goes”
Where data goes in AI AssistThe LLM service is outside your network. Your IDE sends it your prompts and the results of tool calls, and receives answers and requests to call tools. Inside your network, the IDE shows each tool call and asks before it runs, then sends it to the AI Assist MCP server, which runs in a container with a read-only database account and writes every call to an audit log. The server sends read-only SQL to the PeopleSoft database and receives rows from PeopleTools tables, and, through run_select only, from allowed application tables. Code comments, descriptions, and data can contain untrusted text, which reaches the LLM inside tool results.LLM serviceOutside your network, under your provider's termsYour promptsand tool resultsAnswers, and requeststo call toolsYour networkYour IDEMCP host · shows each tool call and asks before it runsTool callsResults, as JSONAI Assist MCP serverContainer · read-only database accountAudit logRead-only SQLRowsPeopleSoft databasePeopleTools tablesDefinitions and codeApplication tablesAllowed tables, through run_select onlyComments, descriptions, and data can contain untrusted text
Tool results travel through your IDE to the LLM service. Whatever a tool returns, including text that someone else wrote, becomes part of the conversation.

Two things follow from this picture:

  • Tool results leave your network. Unless you host the model yourself, the LLM runs at your LLM provider, so everything a tool returns is sent there as part of the conversation. Use a provider, and terms, that your organization has approved for that data. Protecting data lists what each tool returns.
  • Tool results can carry instructions. A PeopleCode comment or a value in a table can hold text written to steer the LLM, and the LLM reads it along with everything else. Prompt injection explains how AI Assist limits what such text can do.

Who is trusted with what

Section titled “Who is trusted with what”
  • You approve tool calls and review answers before acting on them. AI Assist never changes your system; you do, in Application Designer.
  • Your IDE, the MCP host, shows each tool call and asks before it runs, unless you’ve allowed that tool to run without asking.
  • The LLM isn’t trusted to follow only your instructions. It reads text from your database that other people wrote, so AI Assist is designed on the assumption that the LLM can be misled.
  • The AI Assist server is trusted code, but it runs with the least privilege that works: a database account that can read only the tables its tools need.
  • The database enforces that. Whatever the server or the LLM attempts, the account can’t write, lock rows, or read tables it wasn’t granted.

Layers of defense

Section titled “Layers of defense”

Each layer covers a different failure, so no single mistake exposes your system:

Layer What it does
The database account Reads only the tables the tools need. It can’t write, and on Oracle Database it can’t lock rows
Fixed queries Every query is written in advance, with bind variables, so tool arguments can’t change the SQL
run_select controls Off by default. When it’s on: allowed tables only, masked columns, and a separate permission on a shared server
Limits Timeouts, row caps, output limits, and a rate limit per person
Sign-in On a shared server, every request needs an access token issued for the server
Your approval The IDE asks before tools run, so you see every call
The audit log Records every call and every refused request, under each person’s identity

What AI Assist doesn’t protect against

Section titled “What AI Assist doesn’t protect against”
  • Wrong answers. The LLM can misread a definition or draw the wrong conclusion. Check answers against the definitions they name, as each of the Guides shows.
  • Other MCP servers. Your IDE may have other servers connected, such as ones that browse the web or send messages. Combined with AI Assist, they can give injected instructions a way to send data out; see Keep data from leaving.
  • A compromised developer machine. On a local setup, the server and its database password live on each developer’s machine. Protect those machines as you would any machine with database access, or use a shared server, which keeps the password off them.
  • What you share yourself. Anything you paste into the chat goes to the LLM provider too.

In this section

Section titled “In this section”
Read-only accessHow the database account, fixed queries, and limits keep AI Assist from changing or overloading your system.
Prompt injectionHow text in your database could steer the LLM, and what limits the damage.
Protecting dataWhat each tool returns, where it goes, and how to keep personal data out of the conversation.
Audit logWhat the server records, how to read it, and what to watch for.
Security checklistEverything to check before AI Assist goes live.