Privacy Policy

Who this covers

AI Access Gateway (“AAG”, “we”) is operated from Parker, Colorado, United States. This policy explains what personal information we handle, why, and what you can ask us to do about it. It covers this website, enquiries sent to us, and the AAG service itself.

AAG is sold to organizations. Where an organization uses AAG to manage systems on behalf of its own clients, that organization decides what is connected and who may reach it; AAG handles that information on its instructions. This policy describes what AAG does in either role and says which is which.

The short version

• Reading this website tells us nothing about you — see below.
• We do not sell personal information, and we do not use it for advertising.
• AAG does not use customer data, or data obtained through Google APIs, to develop, improve or train machine-learning models, and does not sell it. No code enforces this one. There is no such pipeline in the product and no machine-learning or analytics package anywhere in its dependencies, but that is an absence rather than a control: this promise stands on the contract, and nothing in the software would break if it stopped being kept.
• No AI caller receives credential material — no token, key, secret, certificate or redeemable handle — at any permission level.
• AAG’s request path is not a store of customer business data: a Gateway does not cache what a provider returns, transform it for later or replay it. An audit record describes that a request happened and how it was decided rather than what it returned — with one exception on the failure path, where the provider’s own error sentence is copied into the record verbatim so that a denial can be explained, and a provider that puts data into an error message therefore puts it into the record. One tool is a deliberate exception and it is not the Gateway. The discovery tool, run against an advertising account during onboarding, writes what it reads to files on the machine that runs it — account names, spend over the last 30 and 90 days, and the email addresses and roles of the people who hold access — so that a run stopped by a provider quota can resume instead of starting again. It leaves three files, and its redaction setting masks addresses in the one it renders for reading and in neither of the other two. Separately and durably, AAG stores the identifiers and display names a provider gives for the accounts a Gateway is configured against, because that is the configuration itself.

What we handle

If you only read this website

Nothing is collected by us. This website sets no cookies, runs no analytics, loads no third-party script, font, image or stylesheet, and makes no request to any host but its own. The one thing it stores in your browser is a light or dark preference, kept on your own device, readable only by this site, and not transmitted anywhere.

The company that hosts this website keeps ordinary server logs, which typically include IP address, request time, requested page and user agent. Those are the host’s records, kept under the host’s own terms.

If you contact us

We receive whatever you put in your message — typically your name, email address, employer and the substance of your enquiry — and we keep it so we can answer you and keep a record of the conversation.

If you use AAG

• Account and identity information. Your name, work email address, and the identifiers your identity provider gives us. A person proves who they are to their own organization’s identity provider, which hands AAG a signed token rather than a password; AAG never receives one and so has none to keep. An identity is keyed by issuer and subject together — a bare subject is not an identity, and an email address is never used as the key, so the same address at two issuers is two identities and cannot be confused for one.
• Administrative records. The organizations, security boundaries, connections and role assignments your organization configures.
• Audit records. Security-relevant activity: who did what, when, in which boundary, and whether it was allowed or denied. They are how the service is able to answer “what happened” at all.
• Credential material. The keys, tokens or secrets required to reach an external system you connect. See below.

Credential material

Credential material is treated as a separate category with stricter handling than anything else on this page. Credential material is submitted through one dedicated path that accepts nothing else, and the service that receives it holds an identity which can add a version and cannot read one back — so it is not displayed again after it is entered, and the component that placed it cannot retrieve it. Where AAG needs a credential from a particular person, it records who is being asked, against the requirement being satisfied; AAG sends nothing — no mailer exists in the product — so a message that says it is an AAG invitation did not come from AAG. The material itself always returns through the same dedicated path, and never through an email thread, a chat, a ticket or a screenshot. Credential material is held in Google Secret Manager and encrypted at rest with a customer-managed key. The separation that key buys is by principal rather than by project: the grants on it are to Google’s own Secret Manager and Cloud Storage service agents, so neither a Connector runtime nor the path that accepts new material may use the key directly. A Connector runtime is granted read access to exactly one secret — its own Credential Binding — and the path that accepts new material may add a version and may never read one.

No AI caller receives credential material — no token, key, secret, certificate or redeemable handle — at any permission level.

What happens to it in our audit records, stated accurately. Credential material is screened out of audit records before they are stored, rather than when they are displayed. The screen is a denylist: it catches shapes that name themselves, and AAG does not claim it is exhaustive. A secret with no shape of its own is not distinguishable from any other high-entropy string, and the shapes it admits are written down in the code’s own tests rather than left to be discovered.

Business data reached through a connection

When an authorized caller uses AAG to read something from an external system you have connected — a campaign report, for example — that result passes through AAG on its way back to the caller. AAG’s request path is not a store of customer business data: a Gateway does not cache what a provider returns, transform it for later or replay it. An audit record describes that a request happened and how it was decided rather than what it returned — with one exception on the failure path, where the provider’s own error sentence is copied into the record verbatim so that a denial can be explained, and a provider that puts data into an error message therefore puts it into the record. One tool is a deliberate exception and it is not the Gateway. The discovery tool, run against an advertising account during onboarding, writes what it reads to files on the machine that runs it — account names, spend over the last 30 and 90 days, and the email addresses and roles of the people who hold access — so that a run stopped by a provider quota can resume instead of starting again. It leaves three files, and its redaction setting masks addresses in the one it renders for reading and in neither of the other two. Separately and durably, AAG stores the identifiers and display names a provider gives for the accounts a Gateway is configured against, because that is the configuration itself.

Google user data

AAG uses Google APIs in two places, and only with your explicit authorization through Google’s own consent screen.

• Signing in. When you sign in, we request only your basic profile and email address, and use them to identify you and apply the access your organization has granted you.
• Reading an advertising account you connect. AAG’s Google Ads integration is read-only. It lists the accounts your credential can reach and retrieves campaign performance, on request, for the account you bound it to.

What limits that integration, stated accurately. The Connector Type declares its destinations in its manifest — for Google Ads, exactly two — and the firewall rule is built from that declaration, above a default deny. But an FQDN firewall object resolves a name periodically and then enforces on the resulting addresses, not on the name, and Google API hostnames share address space. So against a Google-hosted provider this rule does not separate this integration’s own Google API from any other Google API. What it does still do, and what matters against exfiltration, is deny every non-Google destination on the internet. The full statement of the limit is in the honest limitations section of the security overview.

AAG’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• We use Google user data only to provide and improve the features you authorized it for.
• We do not transfer it to others except as necessary to provide those features, to comply with applicable law, or as part of a merger or acquisition.
• We do not use it for advertising, and we do not sell it.
• AAG does not use customer data, or data obtained through Google APIs, to develop, improve or train machine-learning models, and does not sell it. No code enforces this one. There is no such pipeline in the product and no machine-learning or analytics package anywhere in its dependencies, but that is an absence rather than a control: this promise stands on the contract, and nothing in the software would break if it stopped being kept.
• We do not read it ourselves, except with your explicit consent, to resolve a specific problem you have reported, for security purposes, or where the law requires it.

You can withdraw AAG’s access at any time from your Google account’s third-party access settings, or by removing the connection in AAG.

Why we handle it

• To provide the service your organization has asked for: establishing who is calling, deciding whether a request is permitted, and reaching the systems you connected.
• To keep the service secure: detecting and investigating misuse, and producing the audit evidence the service exists to produce.
• To answer you when you contact us.
• To meet legal obligations where they apply.

Where the UK or EU General Data Protection Regulation applies to our processing, our legal bases are performance of a contract (providing the service), legitimate interests (security, preventing misuse, and responding to enquiries) and legal obligation. Where we rely on consent — as with Google API authorization — you may withdraw it.

Who else sees it

We do not sell personal information and we do not share it for advertising. We rely on a small number of service providers to run AAG, and every one of them is named on the subprocessors page along with what it is used for and whether customer data can reach it.

We may disclose information where the law requires it, and we would tell you unless we were legally prohibited from doing so. If AAG were acquired, information would transfer as part of that transaction and this policy would continue to apply until it was replaced.

Where it is handled

AAG’s platform infrastructure is deployed in a single Google Cloud region in the United States, on multi-zone managed services. Three things sit outside that region. Database backups and Terraform state are held in Google’s United States multi-region, so they leave the region and stay in the country. The public DNS zones that make a Gateway reachable by name are served by Google’s global name servers, which leaves the country as well: what those zones publish is the hostnames themselves and no customer content. Per-customer data residency is not offered. If you are outside the United States, using AAG means your information is handled there; if residency matters to your organization, raise it before you onboard rather than after.

No customer-facing Gateway is running in production yet, so no customer business data is being processed anywhere today. No code enforces that; it is a statement about the live estate on the date at the top of this page. That is true on the date at the top of this page, and it is the honest frame for everything above: this policy describes what AAG does with information, published before the first customer’s data arrives rather than after.

How long we keep it

• Control-plane audit logs are retained for 400 days. That is the retention period governing audit evidence, and it is not a general schedule: other periods exist for operational reasons — a database point-in-time-recovery window, for one — and no product-wide retention schedule has been set or is published here.
• Enquiries are kept while the conversation is live and for a reasonable period afterwards.
• Account, configuration and audit records are kept for as long as your organization uses AAG.
• Credential material is retained — see below.

Revocation makes a credential unusable rather than destroying it. It is something an AAG operator runs, not something you can trigger yourself: a command run from a checkout by a named person sets the Credential Binding to revoked and removes the Connector Executor’s read grant. That removal is checked rather than assumed — the secret’s access policy is read back afterwards, and if any reader remains, or the policy cannot be read at all, the command says so instead of reporting success. What it does not do is revoke anything at your provider: there is no implementation of that on this estate, in any form. The stored secret and its earlier versions are retained throughout, and destruction on offboarding is specified and is not built. Treat credential material you have given AAG as retained until you also revoke it at the provider, which is the only step that ends the provider’s trust in it.

How it is protected

The controls AAG is built around — refusing by default, credential custody, boundary isolation and the audit record — are set out in detail on the security page, which also states plainly what has and has not been independently verified. AAG holds no security certification, no independent audit report and no penetration-test result, and nothing on this site should be read as one. No code enforces that and none could — it is a fact about the world, and the way to test it is to ask for the report and be told there is none.

No system is beyond compromise. If we discover a breach affecting your personal information, we will notify you and any regulator the law requires, without undue delay.

Your rights

Depending on where you live, you may have the right to ask us for a copy of the personal information we hold about you, to correct it, to delete it, to restrict or object to how we use it, to receive it in a portable form, and to complain to your data protection authority. Residents of California and other United States states with comprehensive privacy laws have equivalent rights, including the right not to be discriminated against for exercising them. We do not sell or share personal information for targeted advertising, so there is nothing to opt out of.

To exercise any of these, email jose@aiaccessgateway.com. We will ask you to verify your identity, and we will not charge you for a reasonable request.

If your information reached AAG because an organization uses AAG to manage systems on your behalf, that organization directs what happens to it. Ask them first; if you ask us, we will pass the request on and help them answer it.

Deleting your data

Email jose@aiaccessgateway.com with the subject line Data deletion request. Tell us which account or organization it concerns.

Be clear-eyed about what we can remove today. Ending AAG’s use of the credential behind a connection, and removing the configuration around it, is a request we act on rather than a button you press. Either way it does not reach into protected storage and wipe the secret. Revocation makes a credential unusable rather than destroying it. It is something an AAG operator runs, not something you can trigger yourself: a command run from a checkout by a named person sets the Credential Binding to revoked and removes the Connector Executor’s read grant. That removal is checked rather than assumed — the secret’s access policy is read back afterwards, and if any reader remains, or the policy cannot be read at all, the command says so instead of reporting success. What it does not do is revoke anything at your provider: there is no implementation of that on this estate, in any form. The stored secret and its earlier versions are retained throughout, and destruction on offboarding is specified and is not built. Treat credential material you have given AAG as retained until you also revoke it at the provider, which is the only step that ends the provider’s trust in it.

Audit records are a second, deliberate exception. Audit records are append-only. A correction is a new event; records are not edited or deleted to change what they say. The evidence store enforces that rather than promising it: a write refuses to overwrite an object that already exists, the identity that writes holds create-and-read and no delete, and the retention policy on this estate has been locked, which puts shortening it beyond an operator and beyond Google. That lock runs for 400 days rather than forever. Being able to remove the record of an action would defeat the reason it exists. Where the law requires personal information inside an audit record to be expunged, we will do what the law requires and record that we did.

Cookies

This website sets no cookies, runs no analytics, loads no third-party script, font, image or stylesheet, and makes no request to any host but its own. The one thing it stores in your browser is a light or dark preference, kept on your own device, readable only by this site, and not transmitted anywhere. Clearing your site data removes the stored preference.

The AAG service itself uses a session mechanism to keep you signed in after you authenticate. That is strictly necessary to operate the service.

Children

AAG is a business product and is not directed at children. We do not knowingly handle the personal information of anyone under 16. If you believe we have, tell us and we will delete it.

Changes to this policy

If we change this policy we will update the effective date at the top and, where the change is material, tell affected customers directly. The version at this address is the current one.

Contact

Privacy questions, requests and complaints: jose@aiaccessgateway.com, or the routes on the contact page. We are in Parker, Colorado, United States.