Skip to main content

Vendor Governance Foundation

Vendor, AI-provider, and incident governance that says the quiet parts clearly.

This G6 foundation explains which outside providers matter, how AgentAlly treats AI-provider routing as a separate disclosure class, how the public list should stay current, and what the company can truthfully say about incident investigation and customer notice without inventing a fake SLA program.

Draft for Counsel ReviewShared-Responsibility Pack

Launch foundation draft for counsel, security, and product review. This page is the G6 transparency layer for named processors, AI-provider routing, change handling, incident governance, and the public-versus-internal commitment split. It does not replace vendor contracts, a DPA, or an internal incident runbook.

Last Updated
April 19, 2026
Effective Date
Pending final launch publication
G6 Boundary

Public commitments, contract terms, and runbooks are not the same layer

This G6 page

Public disclosure and notice baseline

Owns the public explanation of core processors, AI-provider routing, change handling, incident taxonomy, realistic customer-notice posture, and the boundary between published commitments and internal-only procedures.

DPA and vendor contracts

Contractual processor layer

Owns objection mechanics, assistance obligations, region-specific transfer terms, confidentiality covenants, evidence requests, and detailed breach-assistance commitments that do not belong in a short public foundation page.

Internal runbooks and review cadence

Operational incident handling

Owns escalation thresholds, on-call routing, evidence preservation workflow, root-cause analysis, postmortem mechanics, and change-management triggers that should not be represented as a public SLA.

Defined Terms

These terms keep the disclosure and incident-governance layer precise enough to stay believable.

Vendor

A third-party provider, infrastructure service, support tool, integration partner, or other outside service that supports AgentAlly operations or product functionality.

Processor or Subprocessor

A vendor that processes personal data on AgentAlly's behalf or on behalf of an AgentAlly customer in connection with the Service.

AI Provider

A model or AI-infrastructure provider that receives prompts, context, outputs, or derived text for model execution, embeddings, or other AI processing functions.

Security Incident

A confirmed event involving unauthorized access to, disclosure of, loss of, alteration of, or disruption to systems or data that requires coordinated investigation and response.

Personal Data Breach

A Security Incident that meets the applicable legal threshold for breach or reportable personal-data incident under relevant law or contract.

Customer Notice

A notice AgentAlly sends through email, the Service, or another reasonable method when law, contract, or material product-governance expectations require customer-facing communication.

Approval History

Logs or records showing generations, edits, approvals, rejections, overrides, sends, and related metadata used to preserve accountability around approval-gated workflows.

Disclosure Matrix

Core processors and AI providers visible in repo truth

Living List Pattern

Anthropic

Core by default
AI Provider

Runs primary model execution for drafting, summarization, and high-trust reasoning paths.

Product area: Assistive AI workflows and approval-gated drafting
Location note: Region and processing posture subject to provider configuration and final counsel review

OpenAI

Feature-specific or optional
AI Provider

May process text for embeddings and semantic retrieval when embedding-backed memory features are enabled.

Product area: Embeddings, retrieval, and memory support
Location note: Region and processing posture subject to provider configuration and final counsel review

Supabase

Core by default
Infrastructure and data storage processor

Supports application database, storage, authentication, and operational data persistence.

Product area: Core application data and storage
Location note: US-based launch posture expected, subject to environment confirmation

Vercel

Core by default
Hosting and web infrastructure processor

Hosts the application and supports deployment, web delivery, analytics, and operational runtime infrastructure.

Product area: Application hosting and website delivery
Location note: Region and edge behavior depend on deployment configuration

Google

Customer-enabled
Customer-enabled integration and communications provider

Supports customer-enabled Gmail, Calendar, and Drive integrations and related workflow context.

Product area: Inbox, calendar, file, and connected workspace features
Location note: Depends on customer-enabled integration path and provider configuration

GoHighLevel

Customer-enabled
Customer-enabled CRM and lead processor

Supports synced CRM, lead, and workflow data where customers connect that system.

Product area: CRM sync, lead ingestion, and customer operational workflows
Location note: Depends on customer integration posture and provider configuration

Polar

Core by default for paid plans
Billing processor

Supports subscription checkout, account-state, and payment-related workflows.

Product area: Billing and subscription management
Location note: Region and payment-routing posture subject to provider configuration

Sentry

Core by default
Security and observability processor

Supports error monitoring, diagnostics, and incident investigation.

Product area: Application monitoring and security review
Location note: Region and retention posture subject to provider configuration

Mapbox

Feature-specific
Feature-specific mapping vendor

Supports map and location-based product features where rendered.

Product area: Maps and geospatial interface elements
Location note: Depends on provider configuration

Customer-enabled downstream systems

Customer-enabled
Customer-selected integrations and communications channels

Covers customer-authorized systems, carriers, inboxes, or external tools that AgentAlly connects to at the customer's direction.

Product area: Integrations, imports, sends, and downstream delivery
Location note: Varies by customer-selected system

Section 1

Purpose and Scope

This page is AgentAlly's G6 launch foundation for vendor transparency, AI-provider disclosure, and incident governance. It is written to make shared responsibility legible without pretending that a short public page can replace a DPA, vendor contract schedule, or internal response manual.

The purpose is to answer a small set of launch-critical trust questions clearly: which outside providers matter, when AI-provider routing is in the path, how the public list is meant to stay current, how incidents are classified, what customer notice posture AgentAlly can realistically support, and what remains internal or contractual rather than public-facing.

This page should be read alongside the Terms of Service, Privacy Policy, AI Policy, and retention lifecycle foundation. It narrows the focus to disclosure and incident governance rather than trying to restate the whole privacy program in a second voice.

Section 2

Vendor, Processor, and AI-Provider Disclosure Posture

AgentAlly relies on third-party vendors across infrastructure, storage, hosting, model execution, embeddings, billing, observability, integrations, and other support functions. Public disclosure should identify the providers and classes that materially matter rather than collapsing them into a generic service-provider phrase.

AI Providers are disclosed as a separate class because customer content, prompts, context, or derived text may be processed there for model execution or embeddings. Public language should name AI-provider routing directly when it exists and should not suggest that AI processing is merely another invisible infrastructure dependency.

The preferred public mechanism is a maintained list or page that can be updated over time. A one-time policy paragraph is not enough for a launch product whose providers, model routing, and feature-enabled integrations may evolve.

  • Each public disclosure entry should identify the provider name, category, main purpose, affected product area, and whether the provider is core, feature-specific, or customer-enabled where practical.
  • Region or processing-location detail should be included where practical, but public text should not imply immutable hosting or routing if deployment or provider posture can change.
  • Customer-enabled downstream systems should be called out separately so customers understand the difference between AgentAlly's default stack and systems connected at the customer's direction.

Section 3

Public List Maintenance and Change Handling

DPA Seam

AgentAlly should maintain a current public-facing subprocessor and AI-provider disclosure artifact with a named internal owner even before the broader G7 governance matrix is finalized. For launch, the operating owner can be identified as the product, privacy, or trust owner responsible for publication and review cadence.

When AgentAlly materially adds or changes a subprocessor or AI provider, the public list should be updated and a reasonable notice mechanism should be used where applicable. That mechanism can include a website update, in-product notice, email, or another durable communication path rather than a brittle universal deadline promise.

If a customer has a documented concern about a new processor or AI provider, AgentAlly should provide an escalation path. Final objection procedures, commercial remedies, and region-specific contract consequences belong in the DPA or customer agreement rather than being improvised here.

Review Note

Counsel should confirm the final notice workflow, any advance-notice expectation by customer segment, and whether a formal objection mechanism will be public, contractual, or both.

Section 4

Incident Taxonomy and Response Posture

AgentAlly distinguishes between an operational event, a Security Incident, and a Personal Data Breach. An event may involve a bug, outage, false alarm, misconfiguration, or degraded vendor behavior. A Security Incident is a confirmed unauthorized access, disclosure, loss, alteration, or disruption issue that requires coordinated security response. A Personal Data Breach is a Security Incident that reaches the applicable legal or contractual reporting threshold.

This distinction matters because not every outage, vendor disruption, suspicious signal, or internal investigation produces a customer-breach notice. Public language should avoid collapsing every technical issue into a reportable incident.

For suspected Security Incidents, AgentAlly's commitment is process-based: investigate promptly, escalate internally, coordinate with involved vendors, preserve and review available evidence, assess customer and legal impact, and keep a written record of the response process. That is a believable launch posture. Pretending the team can fully understand every incident immediately would not be.

  • Initial investigations may begin on incomplete facts and may change as evidence matures.
  • Information may be provided in phases rather than all at once because first notices rarely contain final root-cause certainty.
  • A notice or update is not, by itself, an admission of fault, liability, or a complete statement of technical causation.

Section 5

Customer Notice and Phased Updates

If AgentAlly becomes aware of a confirmed reportable Personal Data Breach or another event that legally requires customer notice, AgentAlly should provide Customer Notice without undue delay after the relevant threshold is met. The trigger is awareness of a reportable event, not the first hint that something may be wrong.

Customer Notice may occur by email, in-product alert, support contact, or another reasonable method, depending on the situation and the available contact path. Public commitments should stay anchored to legally required notice and material customer impact rather than promising all-customer alerts for every incident.

Where an involved vendor contributes to the incident, AgentAlly should seek prompt cooperation and use reasonable efforts to pass along relevant customer-facing information as facts are confirmed. The public page should describe that expectation, while the detailed assistance language belongs in vendor contracts and the DPA.

Section 6

Vendor Cooperation and Contractual Flow-Downs

Contract Layer

AgentAlly expects vendors that process relevant data to be bound by appropriate confidentiality, privacy, security, and breach-assistance obligations. The goal is not to claim that the public page itself creates those duties, but to say clearly that the contractual layer should support the public notice and investigation posture.

For vendors handling customer or end-customer data, AgentAlly should require reasonable cooperation on incident investigation, notice support, evidence preservation, and security issue remediation as appropriate to the service and risk profile.

Some vendors are core subprocessors, while others are feature-specific or customer-enabled. Public text should preserve that distinction because not every connected system sits in the same contractual or default-processing posture.

Review Note

Security and counsel review should confirm which flow-down obligations already exist, which need stronger language in vendor templates, and which processors require launch-specific DPA review.

Section 7

Approval Accountability and Traceability

AgentAlly's assistive posture still governs this page: users remain responsible for reviewing and approving sensitive outbound actions. Approval-gated workflows are a product control, not a claim that AgentAlly employees manually review every message or document before release.

AgentAlly may keep Approval History and related metadata covering generations, edits, approvals, rejections, overrides, transmissions, and similar operational records for security, compliance, support, auditability, and dispute-resolution purposes.

Changes to approval logic, model-provider routing, logging posture, or other sensitive workflow controls should trigger governance review and may require this page, the Privacy Policy, the AI Policy, or contractual artifacts to be updated.

Section 8

Public Versus Internal Commitments

This page is meant to say what AgentAlly will publicly commit to, while leaving operational detail where it belongs. Public commitments should be durable, understandable, and supportable. Internal procedures can and should be more detailed, but they should not be implied as if the public page were a full runbook or enterprise security manual.

The safest drafting rule is simple: publish the process commitments customers reasonably need to understand, and keep negotiation detail, security-control internals, and response mechanics in the DPA, internal runbooks, and vendor contracts.

Vendor and AI-provider disclosure

Public commitment

Publish and maintain a public-facing list or page describing core subprocessors and AI providers, including vendor name, role class, main purpose, product area, and whether use is core, feature-specific, or customer-enabled where practical.

Internal or contract layer

Maintain the fuller inventory, vendor owner, onboarding review notes, contract references, region detail, retention specifics, and security-review artifacts in internal systems and contract files.

Change notice and escalation

Public commitment

Use a reasonable update mechanism for material additions or changes to subprocessors or AI providers, and provide an escalation path for customers with documented concerns.

Internal or contract layer

The exact timing, objection workflow, transfer analysis, and any suspension or termination remedies belong in the DPA, customer contract, and internal review process.

Incident investigation

Public commitment

Investigate suspected Security Incidents promptly, coordinate with affected vendors where relevant, and provide phased updates as confirmed facts become available.

Internal or contract layer

Escalation matrices, evidence preservation commands, severity scoring, regulator analysis, and postmortem workflow belong in the internal incident runbook.

Customer notice

Public commitment

Provide Customer Notice without undue delay when AgentAlly becomes aware of a confirmed reportable Personal Data Breach or another disclosure-triggering event under applicable law or contract.

Internal or contract layer

Universal 24-hour or 48-hour notice promises, law-by-law thresholds, and specific contractual notification clocks belong in negotiated terms and internal legal review, not this public page.

Approval accountability

Public commitment

Explain that users approve sensitive outbound actions and that AgentAlly may keep Approval History for security, compliance, support, and dispute resolution.

Internal or contract layer

Exact log schemas, retention schedules, export logic, and internal reviewer access controls belong in product architecture, G5 lifecycle governance, and security controls.

Section 9

Updates, Contact Path, and Review Seams

AgentAlly may update this page as the vendor stack, model-routing posture, contract layer, incident process, or legal obligations change. Material changes should be reflected through the website, product, email, or another reasonable notice method before the updated posture becomes operative, unless earlier changes are required for security, abuse-prevention, or legal reasons.

Questions, launch-review feedback, or processor and incident-governance inquiries can be sent to ben@getagentally.com. AgentAlly may later publish a more specific privacy, trust, or security contact path without changing the underlying posture described here.

Open items that still need launch review include final list ownership, provider-region confirmation, the DPA objection workflow, the exact customer-notice channel hierarchy, and any commitments that security or counsel believe should stay internal rather than public.

Review Seams

Product, security, and counsel questions still marked on purpose

  • Confirm the named owner for the living subprocessor and AI-provider disclosure artifact before launch.
  • Confirm the final provider-region posture for Supabase, Vercel, Anthropic, OpenAI, and any communications or analytics vendors before publishing geographic claims.
  • Confirm whether the launch contract set will expose a formal subprocessor objection path or route that issue through case-by-case support and DPA negotiations.
  • Confirm which customer segments, if any, receive advance notice for new subprocessors or AI providers rather than prompt notice through the public list alone.
  • Confirm whether any additional communications, delivery, analytics, support, or payments vendors should be named in the public list before launch.
  • Confirm how incident notices should route when a customer account is suspended, inactive, or missing a current billing or admin contact.
Validation

G6 truth checks baked into the draft

  • AI-provider disclosure is explicit and not buried inside a generic vendor paragraph.
  • The public disclosure structure supports a living subprocessor and AI-provider list rather than a frozen one-time statement.
  • Named vendors reflect repo-confirmed or launch-intended providers rather than made-up enterprise boilerplate.
  • The page distinguishes events, Security Incidents, and reportable Personal Data Breaches.
  • Customer notice language is process-based and avoids fake universal SLA clocks.
  • Vendor cooperation and contractual flow-down expectations are visible without pretending the public page is the full control surface.
  • Approval accountability is described truthfully without implying universal company-side human review.
  • The split between public commitments and internal or contractual commitments is explicit.
  • Open counsel, security, and product seams are marked instead of guessed at.
  • The page stays aligned with G2, G3, and G5 rather than duplicating them wholesale.

Questions or launch-review feedback

Until the final G6 version is published, questions about this vendor, AI-provider, and incident-governance foundation draft can be sent to ben@getagentally.com.

AI-assisted draft prepared for launch counsel, product, and security review on April 19, 2026. This page is a foundation draft and is not effective until AgentAlly publishes the final vendor, processor, and incident governance posture with any required contractual or operational refinements.