eFA Security & Architecture Overview
For customer security reviewers evaluating the eForms Assistant (eFA) feature of GT Forms.
1. What is eFA
The eForms Assistant (eFA) is an AI-powered chat feature built into GT Forms. It has two distinct usage modes:
| Mode | Who uses it | What it answers |
|---|---|---|
| Form Builder Mode | Developers / configurators at the customer site who are building forms | Questions about how to use and configure GT Forms, grounded in GT's public product documentation |
| End User Mode | The actual users submitting forms (e.g., students, employees) | Context-aware questions. When the user is not yet in a form, it can point them to the right form. When the user is inside a form, it answers questions about that form. |
In either mode, eFA is context aware, not user aware — it knows where the user is (in the eFA tile, in a form, which form type) but has no information about who the user is.
How Answers Are Grounded
Answers to End User Questions
Form builders configure eFA at two levels:
- Per-form FAQs — questions and reference material scoped to a specific form (e.g., the "Drop a Class" form has its own FAQ set).
- Shared FAQs — questions that apply across every form (e.g., "How do I contact the help desk?").
These FAQs are authored inside the customer's PeopleSoft environment and pushed to GT, where they become the knowledge base that grounds eFA's responses.
Answers to Form Builder Questions
All answers to form builder questions are crafted based on GT's public documentation on our Docs Site.
2. Core Security Posture at a Glance
| Concern | Answer |
|---|---|
| Is traffic encrypted? | Yes. All customer ↔ GT traffic uses TLS — HTTPS for REST calls and secure WebSocket (WSS) for the chat widget. |
| Does the chat widget use cookies? | No. |
| Does the chat widget use session or local storage? | No. Conversation history is not enabled for the eFA widget, so nothing persists in the browser. |
| Is PII sent to GT? | No. No user identity, no system data, no PeopleSoft transactional data is sent to GT at any point. |
| Where does GT store eFA data? | Oracle Cloud Infrastructure (OCI). No on-prem GT storage. |
| Does any data leave GT's environment? | Only FAQ content and user questions are transmitted to OpenAI, and only during two specific operations. 1. FAQ content is sent to OpenAI to generate vector embeddings, which are subsequently stored within OCI. 2. When a user submits a question, the system retrieves the most relevant FAQ entries using embedding similarity search. The user question and matched FAQ content are then sent to OpenAI to generate a response. |
| How is Peoplesoft to GT server-to-server traffic authenticated? | Signed JWTs (RS256 — RSA with SHA-256). |
3. Architecture
eFA has two independent data flows. Understanding them separately is the key to understanding the security model.
3.1 Setup Flow — Form Builders Pushing FAQs to GT
When a form builder configures FAQs (per-form or shared), the customer's PeopleSoft environment pushes that configuration to GT. GT never pulls from the customer.
What Is Sent to GT in this Flow:
- Form type (the non-sensitive internal name of the form, e.g.,
DROP_CLASS). - The FAQ questions and reference content that the form builder authored.
What is not sent:
- No end-user data.
- No PeopleSoft record data (HR, SIS, finance, etc.).
- No PII.
Transport: HTTPS over the PeopleSoft Integration Broker to a REST endpoint in GT's OCI environment. Authenticated with a signed JWT (RS256).
3.2 Runtime Flow — End User Chatting with eFA
At runtime, the chat widget in the user's browser connects directly to GT over a secure WebSocket. This path does not go through the Integration Broker and does not touch the customer's PeopleSoft database.
What the browser sends to GT:
- The text the user typed into the chat window.
- Context flags only:
- Is the user currently in a form? (yes/no)
- Is this form-builder mode or end-user mode?
- If in a form, the form type (non-sensitive internal name).
What the browser does not send:
- No user ID, username, email, or any other identifier.
- No PeopleSoft session data.
- No form field values.
- No cookies (none are set).
Transport: HTTPS + secure WebSocket (WSS), both TLS-encrypted.
Storage of chat logs: Conversation logs are written inside GT's eFA backend, which lives entirely within GT's OCI tenancy.
4. Where data lives
| Data | Location |
|---|---|
| FAQ source text (authored by customer) | GT vector DB in OCI |
| FAQ embeddings | GT vector DB in OCI (produced by OpenAI, stored back in OCI) |
| Chat logs (user questions + eFA responses) | GT eFA backend in GT's OCI tenancy |
| Cookies / session storage / local storage on user device | None. The widget does not use any browser storage. |
Nothing eFA-related is stored in AWS. Nothing is stored on-premise at GT.
5. Third-party services
OpenAI is the only third-party service in the eFA data path, and it is used for two distinct purposes: generating vector embeddings of FAQ text at the time the customer pushes FAQs to GT and generating an answer from the user question and FAQ text matches.
- The only data OpenAI sees is the FAQ text the form builder authored and the questions the users ask.
- No customer PII is sent to OpenAI.
6. Common customer questions (FAQ)
Q: Does communication between the customer and GT use TLS? Yes, every hop. The setup flow uses HTTPS REST over the Integration Broker. The runtime chat uses HTTPS + secure WebSocket. Note that with eFA, the customer pushes configuration to GT (outbound from the customer). GT does not reach into the customer environment to pull data.
Q: Are cookies stored on end users' devices? No. The chat widget does not set cookies. Conversation history is also not enabled for the widget, so nothing is written to session storage or local storage either.
Q: Is chat data or usage data stored by GT? Yes, inside GT's OCI tenancy only. Chat logs are written to GT's eFA backend in OCI. GT reviews that data only in aggregate to collect usage statistics. Customer-authored FAQ content and its embeddings are stored in an OCI database. Nothing is stored on-prem.
Q: What encryption protocols are used for eFA traffic? TLS for all transport (HTTPS for REST, WSS for the chat channel). Server-to-server API calls are authenticated with JWTs signed using RS256 (RSA with SHA-256).
Q: How much traffic runs through the Integration Broker versus the WebSocket from the browser? Cleanly split:
- All setup traffic (form builders pushing FAQs) goes customer-side PeopleSoft → IB → GT REST API.
- All runtime traffic (end users chatting) goes browser → WSS → GT's eFA backend in OCI → OpenAI REST API. The end user's browser never connects through the customer's Integration Broker.
Q: Is any end-user PII sent to GT? No. The browser sends only the text the user types plus non-identifying context flags (in a form or not, form-builder vs end-user mode, form type name). No user identifier, no PeopleSoft record data, no form field values.
eFA does not pull any PII data from the PeopleSoft environment, but it cannot prevent a user from sending their own PII in the chat text. As such, GT recommends that the eFA welcome message be configured to include instructions to not send private information, along with any other applicable best-practice instructions.
Q: Does eFA know who the user is? No. eFA is context aware, not user aware. It knows what kind of form the user is looking at, not who the user is.
Q: Does eFA have access to our PeopleSoft data? No. The runtime path does not query PeopleSoft records. The only customer-originated content eFA uses to answer questions is the FAQ text the customer's form builders explicitly authored and pushed to GT.
7. Summary
- Two flows, cleanly separated. Setup goes customer → IB → GT REST. Runtime goes browser → WSS → GT. They share no sensitive data paths.
- No PII leaves the customer. Not at setup, not at runtime.
- No browser storage. No cookies, no session/local storage.
- Everything GT stores lives in OCI. Chat logs, FAQs, and embeddings.
- OpenAI's role is narrow. FAQ text for embeddings only; embeddings come back and are stored in OCI.
- Everything in flight is TLS-encrypted. JWT-signed where server-to-server.