Skip to content

Security checklist

Work through this list before developers start using AI Assist, and again after any change to the setup. Each item links to the page that explains it.

  • The server uses a dedicated account, such as AIPS_MCP, never PeopleSoft’s owner ID or access ID. (Create the database account)
  • The account can read the 28 listed tables and nothing else: READ grants on Oracle Database, SELECT on SQL Server, and no roles or system privileges beyond what’s needed to connect.
  • PSOPRDEFN and PSACCESSPRFL aren’t granted. (Tables never to grant)
  • The server’s check command reports ready, with no warnings you haven’t accepted. (Check the setup)
  • The password is kept in a Podman secret, or a file only the service can read, and you know how to change it.
  • Optionally, the account’s sessions are limited, and it’s audited in the database as well.
  • run_select is off, or its allow-list holds only the tables developers need. (Control run_select)
  • Sensitive columns of allowed tables are masked, or left out through views.
  • Copies of production that AI Assist reads have their personal data masked, or run_select is off there. (Copies of production)
  • Your PeopleCode and SQL have been searched for hard-coded secrets, without AI Assist. (Secrets in code)
  • Your organization has approved the LLM provider, and its terms, for the data the tools return. (Where results go)
  • The container is published on 127.0.0.1 only, behind nginx with TLS. (Run a shared server)
  • Sign-in is required, with your identity provider’s issuer and audience configured.
  • Only the people who need to see data have the data scope.
  • allowed_origins is empty, or lists only web origins you trust.
  • The audit log is written to a volume and sent to your central logging system. (Audit log)
  • Developers use IDEs your organization has approved.
  • Approval stays on for run_select. (What you can do)
  • In sessions that use AI Assist, tools that can send data out, such as web access and shell commands, need approval. (Keep data from leaving)
  • The container image comes from your organization’s registry, pulled by its digest so that it can’t change without you noticing.
  • Someone reviews the audit log, with alerts for refused requests, tables that aren’t allowed, and removed hidden characters. (What to watch for)
  • You know how to respond to an incident: turn off run_select, remove access in your identity provider, change the database password, and stop the server if needed.
  • The image is kept up to date.