Privacy policy

1. What we collect

1.1 What you give us

The pilot form on intercis.io/pilot has four required fields and no free-text box: your work email, trimmed and lower-cased before it is stored; your company; your role, from a list; and whether you run agents today, from a list. The sales form on the home page has two required fields: your work email, stored the same way, and one line about what your agents do today, at most 500 characters. Both forms write to the same table, and each submission is mailed to us through Resend. Neither has a name field. Anything else we hold about you came in a message to security@intercis.io or sales@intercis.io, which lands in a Google-hosted mailbox.

Dashboard accounts. An account collects your email address and an authentication credential: a magic link or a password. Supabase Auth hashes the password, and no table in our database has a password column.

Provider API credentials, in passing. Your systems send your own provider key with each proxy request. We hold it in memory for that request, relay with it, and write it to no database; the check in 3.1 does not use it. Keys Intercis issues for proxy access are stored as an HMAC-SHA256 under a server-side secret, and you see the plaintext once.

1.2 What is collected without you typing it

Every page here loads one analytics script: Vercel Web Analytics, served from intercis.io on a same-origin path. Vercel documents it as cookieless: it counts a page view with the path, the referrer, the country, and the class of device and browser. It sets no cookie, writes nothing to your browser's storage, and carries no identifier across other sites. What it records goes to Vercel. An inline script keeps your theme choice in local storage and sends it nowhere. Nothing else runs on this page, which loads no third-party font and no image. A few pages run a small script of our own in the page itself, such as the price calculator on the pilot page; what any page sends us is what you type into it, in 1.1.

Vercel documents that its hosting writes standard server logs, including IP address, browser type and pages requested. The proxy writes its own access log: request id, method, path, status, duration, the caller's IP address and the tenant, never request content. Those lines land in Railway's log store under Railway's retention policy.

1.3 What we do not collect

No advertising cookies or scripts, no session recording, no behavioural profiling. No precise location, though IP addresses our providers handle can suggest an approximate one. No card details: payments run through Stripe's hosted checkout. The dashboard is different: it sets the authentication cookies sign-in needs, and its signup page can load hCaptcha, which sets its own.

Back to contents, from section 1

2. How we use it

• To run the service: your account, and the proxy for your tenant. That means relaying your agents' traffic on the credential your systems supply, and making the safety check in 3.1 on a credential of our own.
• To bill you, through Stripe.
• To answer you: a pilot enquiry, a support question, a security report.
• To decide what to build next, by reading what people ask us for.
• To comply with law and lawful process.

We do not sell or rent your data, and we do not use it for advertising. We share it only with the providers in section 6.

Back to contents, from section 2

3. What leaves, and on whose account

3.1 The relay, and the one exception

The proxy sits between your agents and the provider you configure, Anthropic or OpenAI. Your agents' prompts, tool calls and responses are relayed there on your own API credential, under your existing agreement.

There is one exception. When a tool call reaches the second layer of the check, the request carrying it to the provider is made under an Intercis-owned credential, not yours; the code that picks it refuses to fall back to a client key. That request is billed to us, lands in our provider account, and is covered by Intercis's agreement with that provider, including its terms on training use of API data.

• We have not confirmed in writing which API terms our own Anthropic and OpenAI accounts sit on. Read them as each provider's standard API terms, not as a zero-retention or no-training arrangement.
• There is no per-tenant credential for the check and no switch that turns the second layer off, so there is no opt-out today.

3.2 Which tool calls reach the check, and what it sees

Deterministic rules run first. A call they do not match goes to the second layer only if it can act: it runs code, it writes files, it is an mcp__ tool your runtime would execute, or its name is one we cannot read. Read-only tools are outside that gate. The request carries the tool name and the tool input, which for a file write includes the file contents and for an MCP tool the arguments, which may be a database query.

If the check cannot be made or its answer cannot be read, the call is allowed and the rules are the floor under it. Two columns on your row can carry that: the status of the check, and the reason it could not answer. They are written only behind a deployment flag, and the code ships with that flag off. Where it is off, an allow made while the check was down and an allow the check made look the same on your row. The proxy counts its own unanswered checks as well, and reports the share at https://api.intercis.io/health, which needs no key. That share covers recent checks only, so an idle proxy reports a zero that means nothing.

3.3 Tools the provider runs itself

Tools the provider runs on its own servers have already run by the time the response reaches the API wire we sit on. OpenAI's hosted MCP calls, web search, file search, code interpreter and image generation execute inside OpenAI, and Anthropic's server-run tools inside Anthropic. Each one is observed, not governed: it writes one observe row carrying the tool name and the input the provider reports, and it is never judged or blocked. The tool's output is not copied.

3.4 No training on your data

We do not use your personal information or your organisation's traffic to train a model. 3.1 says which provider agreement covers which request.

3.5 Automated decisions, and this website

Policy decisions are automated and apply to an agent's action, not to a person: an operator sees allow, deny or observe. Intercis makes no solely automated decision producing a legal or similarly significant effect on a person, and no model reads what you send through this website.

Back to contents, from section 3

4. Where it is stored, and how you can check it

4.1 The database

Pilot submissions and audit event rows live in a Supabase PostgreSQL database, and everything in transit is over HTTPS. Our hosting providers state that data at rest is encrypted; that is their statement and we have not audited it.

4.2 What separates one tenant's rows, and what masks a secret

Row-level security is on for eighteen tables, nine of which hold customer data, scoped through tenant membership. Client roles hold no UPDATE and no DELETE on the event log, and no read at all on pilot submissions. Credential material is masked before anything is written down: an assignment, an Authorization header or a URL with a password in it becomes a redaction marker in the stored tool input and in the target excerpt. Masking runs after the decision, so it changes what is kept, not what is enforced.

Sentry collects no user identifiers or IP addresses automatically. There are no user uploads; the storage bucket is not listable, but it is marked public, so an object in it would be fetchable by anyone holding its URL. The security page has the rest of the controls.

4.3 The audit log is tamper-evident, and you cannot check it yourself yet

Two things stand between you and checking it alone. There is no self-serve export carrying the hashes: the dashboard's CSV has eight columns and neither hash is one of them. And the repository holding our own copy of this check is private.

Each row carries a SHA-256 hash over its own fields plus the previous row's hash, one chain per tenant, written by a database trigger before the insert. Each event recorded from 2026-09-20 is hashed over every one of its columns except the tool input, which a nightly job empties at 90 days. Events recorded before 2026-09-20 are hashed over ten named fields, id through created_at below, and are never re-hashed. Every field is length prefixed, so no edit that moves characters across a field boundary leaves the hash unchanged. This is the formula for a row recorded from 2026-09-20:

enc(NULL) = "N"
enc(s)    = len(s) + ":" + s

event_hash = sha256(
    enc(prev_event_hash)
  + enc("2")
  + enc(id)
  + enc(tenant_id)
  + enc(agent_id)
  + enc(action)
  + enc(target)
  + enc(verdict)
  + enc(policy)
  + enc(injected)
  + enc(source)
  + enc(created_at)
  + enc(cloud_provider)
  + enc(region)
  + enc(workload_type)
  + enc(cloud_account_id)
  + enc(cluster_name)
  + enc(command_fingerprint)
  + enc(cc_session_id)
  + enc(cc_agent_id)
  + enc(cc_parent_agent_id)
  + enc(classifier_status)
  + enc(classifier_reason)
  + enc(usage_input_tokens)
  + enc(usage_output_tokens)
  + enc(model)
)

first row of a tenant:
  prev_event_hash =
    sha256(tenant_id as text)

"2" is the format marker,
  and it is hashed too
a row written before
  2026-09-20 drops the
  marker and the fields
  after created_at
len(s)     counts characters
injected   is "t" or "f"
created_at is UTC,
  YYYY-MM-DDTHH:MM:SS.ffffffZ
ids are lowercase uuids
output is lowercase hex

4.4 What neither of those stops

The chain is tamper-evident, not tamper-proof: somebody holding our database credentials could rewrite a tail of the log and recompute the hashes. Catching that takes an earlier hash to compare against, and no endpoint returns one today. The masking above is pattern-based, so it reduces what we store without guaranteeing it.

Back to contents, from section 4

5. One row per governed tool call

5.1 The fields on one row

We do not store your conversation. We store the tool call. The one piece of prompt text we keep is in the last row below: on an injection match the row holds the first 200 characters of the message that matched. Every field on a row that lands is kept for the life of your tenant, except that last one.

5.2 The one automated deletion we run

A nightly job at 03:41 UTC sets raw_request to null on rows older than 90 days, up to 10,000 rows a night. We confirmed on 12 September 2026 that it is scheduled and active on the production database. It is the only scheduled deletion in the service, and nothing deletes the row. That column is also the one left outside the hash chain: hashing it would break every tenant's chain on the night its first row aged out.

5.3 What happens to a row our database will not take

The audit write never blocks your agents, so a database outage cannot stop your pipeline. What it can do is leave a hole in the trail, and the hole is a different shape for each verdict.

• A deny that fails to insert is appended to a spool file on the proxy's own disk and put back in the database after the next insert that works, oldest first. If that write to disk fails, the row is lost.
• A spooled deny the database rejects for good is moved to a dead-letter file beside the spool and never reaches your audit log. We alert on it, when error monitoring is switched on.
• The spool and the dead-letter file beside it both have a size cap. Past it the proxy drops their oldest lines. A deny too large for the cap is not spooled at all, which means that deny is lost. It logs both. The oversized one also raises an alert; dropping the oldest lines does not.
• A row the proxy cannot turn into text is logged and dropped. That one raises no alert.
• An allow or an observe is not spooled. If the database is unreachable that row is dropped and nothing backfills it.

5.4 How deletion works

Your event rows are tied to your tenant by a foreign key that cascades, so deleting your tenant deletes them. The cascade does not reach the spool and dead-letter files in 5.3: those are files on the proxy's own disk, shared across tenants, and nothing in the service takes your lines out of them. Deletion is done by hand, on the timescales in 8.3.

5.5 Everything else we hold, and which routes write a row

Error monitoring

Kept by Sentry for its configured retention period, then expired.

Infrastructure and access logs

Kept by Vercel and Railway under their own policies. We set no period.

Three routes write the row this section describes: Anthropic's messages route, and OpenAI's responses and chat completions routes. Anthropic's token-count route is relayed but judges no tool call, so it writes no governed-call row.

Back to contents, from section 5

6. Processors, named

We share your personal information with the providers below, and in the two situations at the end of this section, and nowhere else.

6.1 Service providers

Supabase

Database hosting and authentication. Supabase privacy policy

Railway

Hosting for the proxy, and its access log. Railway privacy policy

Vercel

Hosting for this site and the dashboard. Vercel privacy policy

Stripe

Payments, through hosted checkout. Stripe privacy policy

Sentry

Error monitoring, scrubbed as 4.2 describes. A report can still carry data from a failing request. Sentry privacy policy

Google

Email hosting. Anything you write to us arrives there. Google privacy policy

Resend

Transactional email. A pilot submission or a message from the home page's sales form is mailed to us through it, so every field of either form passes through. Resend privacy policy

hCaptcha

Bot protection on dashboard signup. It sets its own cookies. hCaptcha privacy policy

6.2 Model providers

Anthropic and OpenAI

Relayed agent traffic on your own credential. Safety checks for gated tool calls on a credential Intercis owns. Anthropic privacy policy. OpenAI privacy policy

6.3 Legal requirements and business transfers

We may disclose information where the law, a court order or other legal process requires it, or to protect the rights, property or safety of Intercis, our users or the public. If Intercis is merged, acquired or sold, information may transfer with it, and we will give notice first.

Back to contents, from section 6

7. Controller and processor

For what you give to intercis.io and dashboard.intercis.io, a pilot submission or an account, we are the controller. For traffic through the proxy, you are the controller and we are the processor, processing on your documented instructions. 9.1 says what terms exist for that today.

We make two choices a pure relay would not. We apply your policy to the tool calls your own runtime would execute, and we choose the provider account the safety check runs on.

Back to contents, from section 7

8. Your rights, and how long we take

8.1 Access, correction and deletion

You can ask for access to your personal information, correction of it, or its deletion. Write to security@intercis.io. We handle these by hand, because the product has no self-serve route for them today.

8.2 EU, UK and California residents

The GDPR and the UK Data Protection Act 2018 give you rights of access, correction, erasure, restriction, portability and objection, and the right to complain to your supervisory authority. The CCPA, as amended, gives you the rights to know, delete, correct, opt out of sale or sharing, limit the use of sensitive personal information, and not be treated differently for asking. We do not sell or share personal information as the CCPA defines those terms.

8.3 How long we take

One month for GDPR and UK requests, extendable by two further months for a complex one with notice to you, and 45 days for California requests. We may need to confirm who you are first. If we refuse a request we will say why.

Back to contents, from section 8

9. What we can sign, and what we lack

9.1 Processing terms

We publish no standard processing contract. A data-processing addendum exists as a draft that no lawyer has yet reviewed, and section 7 is the whole of what we say about our role today.

9.2 If we have a breach

We have no breach-notification procedure written down. What would detect one: the access log, and the alerts the proxy raises on its own checks when error monitoring is switched on. There is no on-call rotation behind that today, because Intercis is one person.

9.3 What we do not have

• No EU or UK representative. None is appointed under Article 27 GDPR or its UK equivalent. If your review requires one named, that is a gap today.
• No outside audit. No third party has examined the claims on this page or the systems behind them, and we hold no attestation and no penetration-test report. Everything here is our own reading of our own code.
• One mailbox. Privacy requests and vulnerability reports arrive at the same address.

Back to contents, from section 9

10. Children, contact and changes

Our services are not directed to children under 13, or under the higher age applicable law sets, such as 16 in parts of the EU, and we do not knowingly collect information from children. If you think a child has given us information, write to security@intercis.io and we will delete it.

Privacy and security: security@intercis.io. Everything else: sales@intercis.io.

When this policy changes we update the date at the top and add an entry to the change record, saying what it used to say. If a change would materially affect how we handle information we already hold, we give notice before it takes effect, by email or on the site. There is no subscribe button and no notification list.

Back to contents, from section 10

11. Where your data is, and on what basis

We operate from the United States. Our Supabase project is us-east-1, read out of our own setup record and not out of a configuration file. Railway's and Vercel's regions are set in each provider's console and written down nowhere we can point you at. Providers in section 6 may process data wherever they operate.

For transfers of EU, EEA or UK personal data to the United States: we have executed no Standard Contractual Clauses with any provider. We rely on the derogations in Article 49 GDPR and their UK equivalents: performance of our contract with you, and steps taken at your request before entering into one.

The bases we process on: performance of a contract for accounts and billing, and legitimate interests for replying to enquiries and for operating and securing our services, which includes error monitoring and logging. For proxy traffic you are the controller, so the basis is the one you set. We do not treat your continued use of the services as consent.

Back to contents, from section 11