Privacy Policy — Data.gov MCP Server (by BLEN)

Last updated: 2026-10-08

This policy describes how the BLEN-hosted Data.gov MCP Server (the Service, operated by BLEN, Inc.) handles information when accessed through its browser portal, Gemini Enterprise, or another MCP client. Self-hosted deployments are governed by their operators' policies.

The Service provides authenticated, read-only access to supported National Park Service (NPS), Federal Election Commission (OpenFEC), and Government Publishing Office (GovInfo) APIs. An organization administrator supplies the agency API key, and authorized members share that organization's connection.

Information we receive

• Google sign-in information: Google account identifier, name, email address, email-verification status, and profile image when provided. Better Auth manages sign-in and account records. We do not receive your Google password. The integration requests identity access, not Gmail or Drive access.
• Dedicated review accounts: when provisioned by an operator, we store a review email, name, membership, and a password hash managed by Better Auth. We do not store the plaintext review password in the account database.
• Organization and authorization information: organization identifiers and names, configured email allowlists, membership roles, browser sessions, OAuth client registrations, consent records, granted scopes, and token records used to authorize MCP access.
• Agency credentials: the api.data.gov key an owner or administrator enters through the authenticated organization portal. Do not include keys in chats, tool arguments, submitted scripts, support messages, or URLs.
• Tool requests and results: search terms, schema paths, JavaScript submitted to execute, query parameters, and agency data retrieved or computed for the request. The Service receives tool requests, not an automatic copy of the entire conversation; your MCP client determines what it sends.
• Network and support information: connection metadata, request headers, and information voluntarily provided when contacting BLEN. Better Auth session records can include an IP address and user agent. The application uses the IP address visible through its configured proxy for request limiting.

How information is used

We use this information to sign users in, enforce organization membership and consent, return requested agency data, manage credentials, prevent abuse, diagnose failures, and respond to support and privacy requests. BLEN does not sell personal information, build advertising profiles from connector use, or train AI models on submitted code, queries, or results. The Service does not itself run a language model.

Tool arguments and public agency records can contain personal information. Submit only information appropriate for the requested public-data query. Do not send confidential records or sensitive personal information through the tools.

Cookies and authentication

The browser portal uses cookies necessary for sign-in, session continuity, and security. Browser sessions are configured with a seven-day lifetime and may be renewed through use. MCP clients receive separate OAuth tokens after explicit consent: access tokens have a 15-minute lifetime and refresh tokens have a 30-day lifetime, subject to rotation and revocation. Expiry limits authorization; it is not a promise that every corresponding database record is immediately erased.

No advertising cookies or browser analytics beacons are embedded by this application. Google's sign-in pages and your MCP client have their own cookie and privacy practices.

Information sent to other services

Google processes sign-in requests. Railway hosts the application and PostgreSQL database and processes hosting and network information. Better Auth runs within this Service; it is not a separate hosted identity service in this deployment.

The search_api and describe_schema tools search bundled documentation locally. During execute, the server sends the selected query parameters, identifiers, and filters to the supported government API, along with the organization's agency key in the X-Api-Key header. Saving a key validates it with an NPS request. The complete JavaScript body runs in a sandbox on our server and is not sent to the agency APIs.

The application does not intentionally forward your Google credentials, MCP bearer token, inbound IP address, or user identity to agency APIs. Outbound requests use the hosting network address. Information you put in query parameters is sent to the selected agency. Results are returned to your MCP client, whose storage and AI processing are governed by its own policies. Hosting, Google, and upstream providers also process information under their applicable policies.

We may disclose information where required by law or necessary to address abuse, security incidents, or threats to the Service.

Storage and retention

• Accounts and access: PostgreSQL stores identity, membership, session, client-registration, consent, and OAuth records. These persist across deployments. Google OAuth tokens stored by Better Auth are encrypted; this Service's opaque MCP access and refresh tokens are stored as hashes. There is no self-service account-deletion feature; contact BLEN about account or organization removal.
• Agency keys: keys are encrypted using AES-256-GCM with organization-bound encryption context. Authorized server code decrypts a key to make an approved agency request. Keys are not exposed to the model or sandbox. An owner or admin can replace or delete the organization's current key through the portal.
• Audit events: credential save, deletion, and re-encryption events record the organization, actor identifier, action, and timestamp, without the key value. The application has no automatic retention limit for these records.
• Rate limits: PostgreSQL stores counters keyed by hashes of IP- or organization-based bucket identifiers. Expired counters are scheduled for cleanup every five minutes while the service is running. A hash is not a guarantee of anonymity.
• Execution: the application has no database or file-storage feature for saving submitted scripts, conversation histories, or agency response bodies. Execution uses temporary child processes, and results and bounded script logs return to the caller. There is no persistent agency-response cache. This does not guarantee that infrastructure or diagnostic records can never contain request information.
• Logs and backups: application logging uses limited startup and generic error messages, and Better Auth diagnostic logging is disabled. Hosting infrastructure may collect additional operational and network logs. Log and backup retention depends on provider settings; this policy does not promise a fixed deletion interval. Deleting a current database record does not immediately remove every historical backup copy.
• Support: information supplied to support is retained as needed to respond and address related operational or legal needs. Contact us about a particular record.

Account, membership, consent, and audit records have no application-wide scheduled deletion period. Contact BLEN for access or deletion requests. We may retain information needed for security, legal obligations, or resolving disputes, and will explain applicable limits when handling a request.

Your controls

Disconnect the connector in your MCP client to stop future calls and use its controls for client-side history. Disconnecting or signing out does not by itself delete server-side records or every OAuth grant. Ask your organization administrator or BLEN to remove membership and revoke access where needed. Owners and admins can remove the organization's stored agency key; this prevents subsequent agency requests using that stored key but does not revoke the key at its issuing agency.

For questions, access requests, or deletion requests concerning BLEN-held information, contact opensource@blencorp.com. Provide your organization and enough context to identify the relevant account or interaction, but do not send credentials. Self-hosted users should contact their deployment operator.

Security

The hosted Service uses HTTPS, membership checks, explicit OAuth consent, PKCE, encrypted agency credentials, request limits, and fixed upstream destinations. JavaScript runs in a fresh sandbox process without direct network, filesystem, environment, or subprocess access. Limits and isolation reduce risk; they do not guarantee protection against every incident. Report vulnerabilities privately to opensource@blencorp.com.

Changes and contact

Updates will be published on this page with a revised date. Privacy questions and requests: opensource@blencorp.com. See also the Terms of Service and BLEN contact page.