AI Governance
| Document status | Public documentation |
| Target audience | Enterprise security & compliance teams |
| Last updated | 2026-01-28 |
Scope of this document
This document provides a technical and architectural overview of Phoenix AI governance controls. It describes current system design, configurations, and operational practices.
This document is not:
- A contractual agreement (see your HG Insights MSA for binding terms)
- A substitute for HG Insights Corporate InfoSec documentation (SOC 2, penetration testing, etc.)
- A guarantee of specific SLAs (see service agreement)
Specific contractual commitments, audit rights, and liability terms are negotiated separately in customer agreements.
Executive summary
Phoenix is HG Insights' AI-powered platform that enables enterprise customers to run intelligent agents for account research and GTM intelligence. Phoenix agents query HG Insights' proprietary third-party data to answer go-to-market questions about target accounts, markets, and technologies.
Key differentiator: Unlike AI tools that process your sensitive internal data, Phoenix's core function is to make HG's data accessible through natural language. Customer data exposure is limited and well-defined.
1. What Phoenix agents actually do
1.1 The core value proposition
Phoenix agents answer GTM questions by accessing HG Insights' data assets:
| Data source | Type | Examples |
|---|---|---|
| Firmographics | HG proprietary | Company size, revenue, industry, locations |
| Technographics | HG proprietary | Technology installations, spend, vendors |
| Intent signals | HG proprietary | Buying signals, technology changes |
| Contact data | HG proprietary | Decision-maker information |
| SEC filings | Public | 10-K, 10-Q analysis |
| News/web | Public | Recent company announcements |
1.2 Customer data: what Phoenix receives
Phoenix receives the following categories of customer data:
| Data category | Description | How it's used | Logged in traces |
|---|---|---|---|
| Target account identifiers | Domains, HGIDs, company names | Input to research queries | Yes (see section 4) |
| Branding assets | Logo URL, brand colors | Output styling | No |
| LLM API keys (optional) | Customer-provided OpenRouter/OpenAI keys | Route LLM calls through customer account | No (redacted) |
| Enablement content (optional) | GTM playbooks, industry messaging, problem-solution mapping | Contextualize outputs for customer's market | Yes |
We recognize that strategic account lists may be competitively sensitive. Target identifiers are logged in execution traces for auditability. Trace access controls are described in section 4.3.
Phoenix does NOT receive or process:
- Customer PII databases
- Customer financial systems or transactions
- Customer internal documents (unless explicitly provided as enablement content)
- Customer CRM credentials (OAuth tokens are used; credentials are never transmitted)
1.3 Composable architecture: bring your own data and models
Phoenix is designed to be highly composable. Customers can swap components to maintain full control:
| Component | Default | Customer option |
|---|---|---|
| Data sources | HG Insights MCP tools | Substitute customer's own MCP tools |
| LLM provider | OpenRouter (Claude/GPT) | Customer's own API keys (OpenRouter or OpenAI direct) |
| LLM routing | Via OpenRouter | Bypass OpenRouter with direct provider keys |
| Agent execution | Phoenix SaaS | On-premises deployment (roadmap) |
Key benefit: If a use case requires first-party customer data, the customer provides their own MCP tool. Phoenix orchestrates the agent, but the sensitive data flows directly from the customer's tool to the LLM. HG never receives or stores it.
Complete OpenRouter bypass: Customers can completely remove OpenRouter from the architecture by providing their own OpenAI API key. When configured:
- LLM calls go directly from Phoenix to OpenAI
- OpenRouter is not involved in any data flow
- Customer's OpenAI contract governs data handling
For the list of HG Insights subprocessors, refer to HG Insights Corporate InfoSec documentation.
2. AI model governance
2.1 LLM provider architecture
Customer Request
│
▼
┌─────────────────┐
│ Phoenix Agent │
│ (Orchestration)│
└────────┬────────┘
│
▼
┌─────────────────┐ ┌─────────────────┐
│ OpenRouter │─────►│ Claude / GPT │
│ (or direct) │ │ (Inference) │
└─────────────────┘ └─────────────────┘
| Component | Provider | Region |
|---|---|---|
| Agent orchestration | HG Insights (Railway) | US |
| LLM routing | OpenRouter (or direct to provider) | Varies by provider |
| Model inference | Anthropic / OpenAI | Varies by provider |
2.2 Data sent to LLMs
When an agent runs, the LLM receives:
- Prompt instructions (HG-authored agent prompts)
- HG Insights data (firmographics, technographics, etc.)
- Target account identifiers (domain, company name)
- Optional customer context (enablement content, persona settings)
The LLM does NOT receive:
- Customer CRM credentials
- Customer API keys
- Bulk customer databases
2.3 Model training policy
No customer data is used for model training.
HG Insights configures OpenRouter with all training/logging disabled:
| OpenRouter setting | Status | Effect |
|---|---|---|
| Paid endpoints training on inputs | Disabled | No training on prompts |
| Free endpoints training on inputs | Disabled | No training on prompts |
| Free endpoints publishing prompts | Disabled | No public dataset exposure |
| Input/output logging | Disabled | No storage with OpenRouter |
| ZDR Endpoints Only | Available | Route only to Zero Data Retention models |
Provider terms:
- Anthropic API: Data not used for training per API terms
- OpenAI API: Data not used for training per API terms
Customer control: Customers can bring their own API keys for additional control over their LLM provider relationship.
2.4 Customer model choice
| Option | Description |
|---|---|
| Phoenix default | Claude 3.5 Sonnet via OpenRouter (privacy settings enabled) |
| Alternative models | Select from any model available on OpenRouter |
| Bring your own keys | Use customer's OpenRouter or OpenAI API keys directly |
| Bypass OpenRouter | Direct OpenAI integration available with customer keys |
| Custom deployment | On-prem agents with customer's LLM infrastructure (roadmap) |
3. Agent architecture
3.1 Read-only by design
Phoenix agents are read-only. They query data sources and generate outputs. They do not:
- Write to customer CRM systems
- Send emails on behalf of users
- Modify external databases
- Execute webhooks or trigger downstream actions
Agents consume data via MCP tools and produce artifacts (briefs, reports). All actions are observable in execution traces.
3.2 Tool-based architecture
Each agent has an explicit tool allowlist defined in its configuration:
# Example: Account Research Agent
tools:
- company_firmographic # HG data - read only
- company_technographic # HG data - read only
- company_spend # HG data - read only
- sec_filing_section # Public data - read only
Agents cannot call tools outside their allowlist.
3.3 Tenant tool control
Customers control which tools their agent instances can access:
| Control | Description |
|---|---|
| Enable/disable tools | Turn off specific MCP tools per tenant |
| Tool substitution | Replace HG tools with customer's own MCP tools |
| Parameter defaults | Set default research depth, persona, output format |
4. Execution tracing and auditability
4.1 What gets logged
Every agent run captures:
| Trace element | Description | Stored |
|---|---|---|
| Run metadata | Agent version, tenant, user, timestamp | Yes |
| Tool calls | Which tools called, with input parameters | Yes |
| Model usage | Provider, model, token count, latency, cost | Yes |
| Outputs | Generated artifacts (briefs, reports) | Yes |
| Errors | Exceptions and failure details | Yes |
Retention: 2 years default. Shorter retention available for Enterprise tier customers.
Minimal logging mode: Enterprise customers can enable minimal logging, which stores only run metadata (cost, user, timestamp, success/failure) without input parameters or output content. Note that even with minimal logging enabled, prompts are still transmitted to LLM providers per their data handling terms.
4.2 What does NOT get logged (redaction)
Sensitive fields are automatically redacted before storage (not after retrieval):
- OAuth tokens and refresh tokens (
Bearer *,access_token,refresh_token) - API keys (patterns:
sk_live_*,sk_test_*,sk-*,sk-ant-*,phx_*,AKIA*,AIza*) - Passwords and credentials (field names:
password,secret,credential) - JWT tokens
- Database connection strings (PostgreSQL, MySQL, MongoDB, Redis)
- Customer LLM API keys
Redaction events are logged for audit purposes (field redacted, pattern matched) without exposing the original sensitive values.
4.3 Trace access controls
| Role | Access |
|---|---|
| Customer admin | Own tenant's traces only |
| Customer end-user | Results only (trace access configurable per tenant) |
| HG Support | Requires customer-initiated support ticket; audit-logged internally |
HG Support access policy: HG personnel cannot access customer tenant traces without a customer-initiated support ticket. All support access is logged. For Enterprise customers requiring additional controls (e.g., explicit approval workflows), discuss with your HG representative.
5. Output governance
5.1 What agents produce
- Account research briefs - HTML/PDF one-pagers about target companies
- Structured data - JSON/CSV exports of research findings
- Recommendations - Suggested talking points, competitive insights
5.2 Output quality controls
| Control | Description |
|---|---|
| Source grounding | Outputs generated from HG proprietary data, reducing hallucination risk |
| Source attribution | Briefs include citations to data sources |
| Output logging | All outputs stored for quality auditing |
| Structured prompts | Agent prompts enforce consistent output format |
5.3 Output accuracy disclaimer
Phoenix outputs are generated by AI models and are intended for informational purposes. While outputs are grounded in HG Insights data:
- HG Insights does not warrant the accuracy of AI-generated content
- Human review is recommended before business decisions
- Specific accuracy SLAs can be discussed in Enterprise agreements
Customers can configure output disclaimers to appear on generated artifacts.
5.4 Output ownership
Generated outputs belong to the customer tenant. HG Insights:
- Does not use outputs to train models
- Does not share outputs across tenants
- Retains outputs per retention policy (default 2 years; configurable for Enterprise)
6. Infrastructure and data residency
6.1 Current deployment (SaaS)
| Component | Provider | Region |
|---|---|---|
| Agent Service | Railway | US |
| Database | NeonDB (PostgreSQL) | US |
| Artifact Storage | AWS S3 | US |
Tenant isolation: Logical isolation via per-tenant database schemas and scoped API access.
Data residency: Currently US-only. EU or region-specific deployment is not available in the current architecture. Hybrid/on-prem deployment (roadmap) would enable customer-controlled data residency.
6.2 Roadmap: hybrid/on-premises
For enterprises requiring additional control:
- Agent execution on-premises - Run agents in customer infrastructure
- Configuration from Phoenix - Manage agent definitions via Phoenix UI
- Customer-controlled LLM - Use customer's own LLM deployment
- Customer-controlled data residency - Data stays in customer environment
Contact your HG Insights representative for roadmap timing.
7. Risk profile summary
7.1 Why Phoenix has a favorable risk profile
| Risk factor | Phoenix posture | Rationale |
|---|---|---|
| Customer PII exposure | Low | Agents query HG data, not customer PII |
| Data exfiltration | Low | No bulk customer data processing |
| Model training | None | OpenRouter settings + provider API terms |
| Autonomous actions | None | Agents are read-only; no writes to external systems |
| Output hallucination | Mitigated | Grounded in HG data with source attribution |
7.2 Security controls
| Control | Implementation |
|---|---|
| Input validation | Domain validation (TLD checks, blocklists), HGID format validation, input size limits (1KB/param, 10KB total), prompt injection pattern detection |
| Prompt architecture | XML-delimited system instructions, immutable assistant identity, role-locking constraints, explicit boundary between system and user content |
| Output constraints | Structured prompts enforce format boundaries, source attribution required |
| Trace redaction | Automatic redaction of OAuth tokens, API keys (Stripe, OpenAI, Anthropic, AWS, GCP), passwords, JWTs, and connection strings before storage |
| Tenant isolation | Per-tenant database schemas; scoped API access |
| Rate limiting | Per-tenant concurrency limits (default: 10 runs) |
8. Frequently asked questions
Does Phoenix have access to our Salesforce data?
Only if you explicitly provide an MCP tool that connects to your Salesforce. By default, agents only access HG Insights data.
Can Phoenix agents modify our systems?
No. Phoenix agents are read-only by design. They query data and generate outputs. They cannot write to CRMs, send emails, or trigger external actions.
Can we bypass OpenRouter entirely?
Yes. Customers can provide their own OpenAI API key. When configured, OpenRouter is completely removed from the data flow. LLM calls go directly from Phoenix to OpenAI. Your OpenAI contract then governs data handling.
Where is our data stored?
Currently US-only (Railway, NeonDB, AWS S3). Hybrid deployment enabling customer-controlled data residency is on the roadmap.
What if we need shorter data retention?
Default is 2 years. Shorter retention (or immediate deletion) is available for Enterprise tier customers.
Can we disable logging of our inputs?
Yes (Enterprise). Minimal logging mode stores only run metadata (cost, user, timestamp, success/failure) without input parameters or output content. Note that prompts are still transmitted to LLM providers regardless of logging settings.
Is our data used to train AI models?
No. OpenRouter privacy settings are disabled, and provider API terms prohibit training. Customers can use their own API keys for additional control.
Can we audit Phoenix?
Execution traces are available via Phoenix UI and exportable. Broader audit rights (infrastructure, subprocessors) are addressed in Enterprise agreements.
Can we run Phoenix in our own environment?
Roadmap. Hybrid deployment (agents on-prem, configuration via Phoenix) is planned. Contact your HG representative for timing.
9. Contact information
| Contact type | Details |
|---|---|
| Enterprise sales | Contact your HG Insights representative |
| Security & compliance | Refer to HG Insights Corporate InfoSec |
| Contractual terms | Refer to your HG Insights MSA |
Document control
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2025-12-11 | Phoenix Team | Initial draft |
| 0.2 | 2026-01-28 | Phoenix Team | Clarified data categories, read-only architecture, residency, disclaimers |
| 0.3 | 2026-01-29 | Phoenix Team | Detailed security controls implementation (input validation, trace redaction, prompt hardening) |