OnRamp AI: Data Flow & Security Overview

Audience: Customer security, infosec, and engineering reviewers Purpose: Explain how OnRamp's AI features handle data — where it flows, how tenants are isolated, and what controls govern access

---

1. Purpose and Scope

This document explains how OnRamp's AI features work from a data-flow and access-control perspective. It is intended for security and engineering reviewers performing an infosec assessment as part of customer procurement or ongoing program governance.

What this document covers:

• The set of AI features in OnRamp and how users interact with them
• End-to-end data flow for an AI request
• The tenant isolation model (organization scope and customer-account scope)
• Role-based access control as it applies to AI-initiated queries
• The read-only database access architecture and its layered defenses
• Column-level data exposure controls
• Write actions and human-in-the-loop approval gating
• The LLM provider relationship and how external inference is handled
• Session management and audit logging

What is intentionally out of scope:

Internal infrastructure identifiers, deployment topology specifics, and source-tree references. This document is meant to give a reviewer enough technical substance to evaluate OnRamp's posture without requiring access to internal implementation details.

---

2. AI Features in OnRamp

OnRamp embeds AI assistance across several distinct surfaces. Each surface operates under the same underlying security model, but the interaction patterns vary.

Surface	Audience	Pattern	Capabilities
Aero AI copilot	Organization users (your team)	Conversational, in-app	Read-only data lookups scoped to the user's organization; advisory guidance; gated action proposals
Portal copilot	Portal users (your customers)	Conversational, in-portal	Read-only data lookups scoped to the customer's own account; advisory guidance; user-confirmed action proposals
Playbook builder	Organization users	Goal-directed authoring assistant	Drafts playbook structures based on user prompts; output is a proposal that requires the user to explicitly save
Insights summarization	Organization users	Dashboard-attached explanations	Generates natural-language summaries of already-scoped dashboard data
Re-engagement analysis	System-initiated; no end-user in the loop	Scheduled batch	Analyzes project signals and writes recommended actions for organization users to review later

A lightweight router agent sits in front of the user-facing surfaces. It classifies the user's intent and dispatches the request to the appropriate domain agent. The router does not access data; it routes intent only.

---

3. High-Level Data Flow

The diagram below traces a single user request from the browser, through OnRamp's backend, into the AI runtime, and back. Two paths are illustrated: the prompt path (always present) and the optional read path (when the AI consults application data to answer the question).

sequenceDiagram
    participant User as End User
    participant UI as OnRamp UI
    participant API as OnRamp Backend
    participant Runtime as AI Runtime
    participant LLM as AWS Bedrock - Anthropic Claude
    participant Data as Application Database

    User->>UI: Enters prompt
    UI->>API: POST prompt and session token
    Note over API: Verify session and resolve caller identity
    API->>Runtime: Forward prompt with verified caller context
    Runtime->>LLM: System prompt and user prompt
    LLM-->>Runtime: Model requests a read tool
    Runtime->>API: Invoke read tool with caller context
    API->>Data: Execute SQL - scope-injected and RLS-protected
    Data-->>API: Rows scoped to caller tenant and role
    API-->>Runtime: Tool result
    Runtime->>LLM: Synthesize response with tool result
    LLM-->>Runtime: Streamed response tokens
    Runtime-->>API: Stream tokens via Server-Sent Events
    API-->>UI: Stream to browser
    UI-->>User: Render answer

A few observations worth highlighting for a reviewer:

• The user never speaks to the LLM directly. Every request passes through OnRamp's authenticated backend, which attaches the caller's verified identity before any AI processing occurs. The browser never holds AI provider credentials.
• The LLM cannot reach the database. It can ask the AI runtime to execute a tool, but every tool call is mediated by OnRamp's backend, which enforces tenant scoping at the SQL layer (see Section 6).
• Streaming uses Server-Sent Events over the existing authenticated channel. No additional ports or out-of-band connections are opened.

---

4. Tenant Isolation Model

OnRamp uses two complementary layers of tenancy:

• Organization scope — your organization, as an OnRamp customer. Every business record in the system is tagged with an organization identifier. One organization's data is never present in another organization's queries.
• Customer-account scope — within an organization, individual customer accounts (i.e., the customers you are onboarding through OnRamp). When the AI is invoked from a portal session, customer scope is additionally enforced on top of organization scope.

flowchart TB
    subgraph V1[Organization A]
        UA[Org A team - Aero copilot]
        P1[Customer 1 portal user]
        subgraph C1A[Customer 1]
            D1[Records for Customer 1]
        end
        subgraph C2A[Customer 2]
            D2[Records for Customer 2]
        end
    end
    subgraph V2[Organization B]
        UB[Org B team]
        DB1[Records for Org B]
    end
    UA -->|can read| D1
    UA -->|can read| D2
    P1 -->|can read| D1
    P1 -.->|BLOCKED| D2
    UA -.->|BLOCKED| DB1
    P1 -.->|BLOCKED| DB1

The model is structurally enforced at the database query layer, not as a UI hide:

• An organization user (Aero copilot session) can see data across the customer accounts within their own organization, subject to role.
• A portal user (portal copilot session) can see data only for the customer account they are mapped to. Same organization, different customer account = no visibility.
• Cross-organization visibility is impossible regardless of role, query shape, or interaction path.

---

5. Role-Based Access Control

The AI agent has no role of its own. It runs inside the calling user's authenticated session and inherits that user's role. The role-based permissions that govern the rest of OnRamp apply equally to data the AI fetches.

OnRamp's role model includes organization-level human roles (admin, owner, creator, collaborator, contributor) and machine roles (API service tokens). Per-role filters are applied on top of tenant scope:

• API service tokens are denied free-form AI data queries. Integrations must use explicit, scoped REST endpoints with the appropriate authorization scopes. This deliberately limits blast radius if a long-lived integration token is ever compromised — a stolen token cannot be used to issue open-ended natural-language queries through the AI.
• Contributor role (the most restricted human role with AI access) sees only data tied to projects they are explicitly a member of, even when querying tables their role can otherwise view through the UI.
• Standard human roles (admin, owner, creator, collaborator) see their organization's data subject to the same row visibility rules they would have through any other OnRamp UI surface.

A contributor asking "what's overdue across the organization?" receives only tasks within projects they belong to. This is not a UI filter; it is applied as a WHERE clause inside the executed SQL.

---

6. Read-Only Database Access: Defense in Depth

When a question maps to a well-defined data shape (for example, "what tasks are assigned to me on this project?"), the AI uses a narrowly-scoped read tool whose parameters and return shape are fixed in advance. Free-form SQL is reserved for open-ended questions where a fixed-shape tool does not exist. Both paths run through the same identity, scoping, and audit controls; this section focuses on the SQL path because it is the broader of the two — narrowing it is enough to bound the rest.

OnRamp enforces tenant and role scoping on the SQL path through four independent defenses. Any single layer would be sufficient on its own; together they make cross-tenant reads structurally impossible.

flowchart LR
    A[AI generates SQL] --> B[Layer 1<br/>Identity verification]
    B --> C[Layer 2<br/>Query validation<br/>and rewrite]
    C --> D[Layer 3<br/>Read-only DB role<br/>SELECT-only on allowlist]
    D --> E[Layer 4<br/>Row-Level Security<br/>policies]
    E --> F[(Scoped result rows)]
    style B fill:#fff4e6,color:#000
    style C fill:#e6f3ff,color:#000
    style D fill:#e6ffe6,color:#000
    style E fill:#ffe6f3,color:#000

Layer 1 — Identity verification. Before any query runs, the SQL endpoint cross-checks the asserted caller identity (organization, user, portal flag, customer mapping) against the authenticated database record. For portal users, the customer-account mapping must exist and be active. Any mismatch fails the request before the query is parsed.

Layer 2 — Query validation and rewrite. The SQL string is parsed into an abstract syntax tree, validated against a strict shape policy (no write statements, no SELECT *, no recursive CTEs beyond a shallow depth, no database-internals or large-object access, no multi-statement payloads), and then rewritten before execution. The rewrite injects the caller's organization and customer scope into every part of the query — including subqueries, common table expressions, UNION arms, and EXISTS clauses. Queries that cannot be safely scoped (for example, a referenced table has no resolvable tenant column) are rejected outright. A result-size cap is also injected.

Layer 3 — Dedicated read-only database role. The AI runtime authenticates to PostgreSQL as a dedicated read-only role. This role has SELECT granted only on a defined allowlist of tables. It has no INSERT, UPDATE, DELETE, or schema-modifying privileges of any kind, and a statement timeout is enforced at the role level to prevent runaway queries. Even a hypothetical bug in an upstream layer that emitted a write statement would be rejected by the database engine itself.

Layer 4 — PostgreSQL Row-Level Security (RLS). Tables protected by RLS carry policies that restrict the read-only role to rows matching the caller's scope, set as a transaction-scoped database variable. If a query somehow reached the database without proper scope injection, the database engine would return zero matching rows for that caller.

All four layers are independent. A failure or oversight in any one is contained by the others.

Every query — accepted or rejected — is logged with the full caller context to OnRamp's audit pipeline, including the original SQL, the rewritten SQL, the result row count, and any rejection reason.

---

7. Column-Level Data Exposure

OnRamp does not expose database tables to the AI by default. Every column on every table that the AI can query carries an explicit exposure classification.

Classification	Effect
Public	Visible to AI queries from any authenticated session, subject to row scope
Confidential	Visible to organization-user AI sessions only; structurally hidden from portal-user (customer-facing) AI sessions
Internal	Never visible to any AI session — reserved for passwords, API tokens, internal hashes, integration credentials

A small set of low-sensitivity, structurally common columns (record identifiers, audit timestamps, soft-delete markers) are auto-classified as Public. Every other column requires an explicit classification before the AI can read it.

A continuous-integration check fails the build if any column on an AI-exposed table is missing a classification. The practical result: a developer cannot accidentally expose a new sensitive column by forgetting to mark it. Forgetting is a build failure; the default behavior is denial.

Column names matching sensitive patterns (password, token, secret, api_key, ssn, tax_id, routing, account_number, credit_card, and similar) trigger additional review before a Public classification can be applied.

---

8. Write Actions and Approval Gating

The AI does not modify customer data without explicit user confirmation. The architecture enforces this at the runtime level, not as a UI convention.

flowchart TB
    Start[AI plans a tool call] --> Type{Tool type}
    Type -->|Read tool| Read[Execute inline under scope guarantees from Section 6]
    Type -->|Write or action tool| Gate[Pause execution and surface approval prompt to user]
    Gate --> User{User decision}
    User -->|Approves| Execute[Execute action under user authorization]
    User -->|Declines| Cancel[Tool cancelled and AI receives declined signal]
    Execute --> Audit[Action logged with user, time, target, parameters]
    Cancel --> Audit
    Read --> Audit

Read-only tools (data lookups, summaries) execute inline within the AI turn — they are bounded by the read-path defenses in Section 6.

Action tools (modifying a project, updating a task, sending a notification) are tagged in the system's capability registry as requiring user confirmation. When the AI proposes one, the runtime interrupts execution and surfaces an approval prompt to the user describing the target, expected effect, and eligibility. The action only proceeds if the user explicitly approves. Approval state is recorded against the session so a single approval cannot be silently replayed for a different action.

If a capability is disabled for the organization or ineligible in the current context, the AI is not given the option to propose it — the tool is not even surfaced. This prevents the AI from offering actions a user could not actually take.

---

9. LLM Provider and External Data Handling

OnRamp uses AWS Bedrock for all AI inference. Bedrock-hosted Anthropic Claude models are used: a Claude Sonnet-class model for the user-facing orchestrator agents and a Claude Haiku-class model for the lightweight intent classifier (router).

Operational characteristics relevant to a security review:

• Hosting boundary. Inference runs in AWS, within OnRamp's AWS environment, via IAM-authenticated calls to the Bedrock service. OnRamp does not send prompts to Anthropic's own API. Anthropic provides the model weights to AWS Bedrock; Anthropic does not receive customer data through OnRamp's integration.
• Region. Inference runs in US AWS regions. No cross-region replication of prompts or responses occurs as part of OnRamp's integration.
• No training on customer data. Per AWS Bedrock's service terms, Bedrock does not use customer prompts or responses to train the underlying foundation models, nor share them with the model providers. This is an AWS commitment that applies to all Bedrock customers.
• Content filtering. All user-facing inference calls are configured to run through managed AWS Bedrock Guardrails, which apply content moderation policies before responses reach the user.
• What gets sent to the model. The payload to the model is the system prompt (OnRamp-authored), the user's prompt, and any tool results retrieved during the turn. Tool results have already been scope-filtered by the read path described in Section 6 — the model never receives rows outside the caller's authorized scope.

---

10. Session Management

Every AI interaction runs inside an authenticated OnRamp session. Sessions are tracked server-side, not only as a browser cookie:

• On login, OnRamp records the session in its database with a cryptographically secure token (256 bits of entropy, URL-safe encoded), the client IP address, user agent string, and a 30-day expiration. The token is bound to the user's account.
• Every authenticated request to the AI endpoints validates the session against this server-side record. Expired or invalidated sessions are rejected before any AI processing occurs.
• On logout, the server-side session record is marked invalidated immediately. The token cannot be reused — even if it was previously captured by an attacker. This closes the common attack pattern of cookie reuse after logout.
• Session activity timestamps are tracked and available for forensic review. A scheduled job purges old records past a configurable retention window.

---

11. Audit and Monitoring

The AI runtime emits audit records for:

• Every prompt received (user, organization, timestamp)
• Every tool invocation — read or action — with parameters and result outcome
• Every SQL query attempted, accepted or rejected, including the original and rewritten text, row count, and any rejection reason
• Every approval prompt surfaced and its resolution (approved, declined, timed out)

Records are forwarded to OnRamp's centralized observability pipeline for retention, monitoring, and alerting. Anomalous patterns — for example, an unusually high rate of query rejections from a single session — are surfaced to OnRamp's on-call rotation for review.

---

12. Summary of Guarantees

For a security reviewer compiling an assessment, the following structural guarantees apply:

1. Cross-organization data is structurally inaccessible. Four independent defenses (identity verification, scope-injected query rewrite, read-only database role, row-level security) enforce tenant boundaries. No single bug breaks isolation.
2. Portal users see only their own customer's data. The same defenses apply customer-account scope on top of organization scope for portal sessions.
3. The AI inherits the calling user's role. It cannot read data the user could not access directly through the OnRamp UI.
4. Default-deny on data exposure. A new column is invisible to the AI until explicitly classified. The build fails on omission.
5. Secrets are never visible. Passwords, API tokens, integration credentials, and internal hashes are categorized as Internal and excluded from every AI session.
6. Writes require explicit human confirmation. The AI cannot modify customer data unattended. Action tools pause and surface an approval prompt; nothing proceeds without it.
7. All inference runs on AWS Bedrock in US regions. Customer data is not sent to Anthropic's own API. AWS does not train foundation models on Bedrock customer prompts.
8. Sessions are server-validated. Captured tokens cannot be reused after logout.
9. Everything is audited. Prompts, tool calls, queries, approvals — all logged with caller context, available for review.

For questions that map to a specific security questionnaire (SIG, CAIQ, or a custom format), contact OnRamp's security team.