Trust & Security

Last reviewed: August 7, 2026

This page describes how Meta Council handles customer data and what protections are actually in place today. It is written for the security reviewer who has to approve or reject us, so it is specific, it names what we do not have, and it points at things you can verify yourself without taking our word for anything.

If something you need is not answered here, write to the address in our security.txt and we will answer it directly rather than guess in public.

What we do not have

Putting this first is deliberate. A vendor who hides gaps until the audit stage costs you more than one who names them up front.

Every item above is tracked work with an owner and a target date. See Roadmap.

What you can verify yourself, right now

You do not need an account or our cooperation to check any of this:

curl -sI https://meta-council.com/ | grep -i 'strict-transport\|content-security\|x-frame\|referrer\|permissions'
curl -s  https://meta-council.com/.well-known/security.txt

Audit trail you can export

You can pull your own workspace's agent-action records and load them into your own SIEM. Each event says what triggered the action, which identity authorized it, which resource was touched, the outcome, and the error state on failure. It is metadata only: no prompt text, no document content, no tool arguments, no model output.

What it does not cover, stated plainly. This is a documented subset of platform activity, not every action. Three event types carry the acting account's identity and therefore reach your export: hosted MCP tool calls, and two redaction-gate events. Six further event types are recorded without an account — four of them are refusals that happen before authentication resolves an identity, so there is no account they could belong to. Actions taken through the web UI, through other REST routes, and by the scheduler are not on this trail today. An export that returns nothing for a period is evidence that nothing covered happened, not evidence that nothing happened.

These records are written on a best-effort channel, not one that is transactionally coupled to the change it describes — that stricter coupling is currently installed on four of 110 registered mutators. A missing event is therefore possible in principle, and this export should not be read as proof that an action did not occur. Timestamps are assigned by the database, never by application code, and no route updates or deletes an audit record; that is a narrower guarantee than database-enforced immutability, which we do not yet hold for these rows.

Account and credential handling

• Passwords are hashed with bcrypt using a per-password salt. We never store or log a plaintext password.
• Login does not reveal whether an email is registered. The same hashing work runs whether or not the account exists, so response timing cannot be used to enumerate customers.
• API credentials are hashed at rest, carry explicit scopes, support expiry and revocation, and record last-used metadata. A key that can read tickets cannot write them unless it was issued that scope.
• Provider and tool secrets you supply are encrypted. If the encryption key is unavailable, new secret writes fail closed rather than falling back to storing anything in the clear.
• Administrative login is rate-limited per source address.

Tenant isolation

• Authenticated sessions are private by default. Content is not public unless it is explicitly made public.
• Generated artifacts are bound to the owning account.
• Retrieval against the knowledge base applies a tenant filter on the way out and re-checks tenancy on the returned results, failing closed if the two disagree. A filter bug alone is not sufficient to leak another customer's content.
• Custom workflows are owner-isolated, with bounded definitions, per-account quotas, atomic writes and fail-closed collision checks.

Request handling and abuse limits

Origin validation and rate limiting apply at the edge. Request size ceilings are enforced before parsing, not after, and uploads are bounded on file count, total bytes, decompressed expansion, parser concurrency and wall-clock time. This is as much a denial-of-service control as a correctness one.

AI model providers and your data

Prompts have to go somewhere. Which company receives yours, and what they are permitted to do with them, depends on one choice you make — so this section is organised around that choice rather than around us.

Platform-supplied models

When you use platform-supplied inference, prompts are sent to a third-party model provider under our contract with them. That is one company: Anthropic. Our software can dispatch to eleven model providers, but exactly one holds a credential in production, so platform-supplied prompts reach one provider and not the other ten.

Under Anthropic's published commercial terms, which are the terms we operate under: Anthropic is contractually prohibited from training its models on our customers' content, that content is treated as our confidential information, and inputs and outputs are deleted within 30 days. That 30-day figure carries stated exceptions — features whose retention you control, enforcement of their usage policy, legal compliance, and any arrangement separately agreed — and we state them alongside it because "deleted within 30 days" on its own would claim more than the contract gives.

Anthropic offers a zero-retention arrangement, but it is granted per organisation on request rather than enabled by a setting. We are not asserting on this page either that we hold one or that we do not, because that is a fact about our account rather than about our software, and this page is for claims you can hold us to. If your deployment requires zero retention, ask us and you will get a straight answer about what is and is not in place.

Bring your own key

Meta Council supports running your councils and workflows under your own model provider key. In that mode your prompts and outputs travel under your contract with that provider, on your data handling terms, and your provider relationship — including any zero-retention or no-training terms you have negotiated — governs directly. For many security teams this is the shortest path to approval, because it removes us from the question entirely.

It also removes us from the protection. Bringing your own key is not automatically the more private choice, and we would rather say so than let the paragraph above imply otherwise. Of the eleven providers we can dispatch to, several use submitted content to train or improve their models unless the customer changes a setting or negotiates different terms; at least one major provider draws the line at its paid tier and tells users in its own terms not to submit confidential information on the free tier, where human reviewers may read what is sent. Your prompts under your key are governed by your provider and your plan — including which billing tier that key is on, which is something we cannot see and cannot check for you.

We keep a dated record of what each of the eleven providers publishes about training use, retention and zero-retention availability, with the source and the date it was read. Ask us and we will send it, or answer for the specific provider and plan you are considering. We would rather do that than summarise eleven contracts into one reassuring sentence.

One exception, stated plainly

Every path that runs a council, a workflow, an outreach draft or a ticket plan uses your key when you have supplied one. One internal batch job does not. A maintenance task that groups internal failure reports runs on our own provider credential rather than a customer's, by design — and a failure report can quote the content that failed. The job is disabled by default and off unless explicitly enabled. We are naming it because a customer who has supplied their own key is entitled to know the one place that choice is not honoured, and because you would have no way to discover it from outside.

We do not train models on customer content. Meta Council does not build or fine-tune models from your prompts, outputs, or documents.

Data retention and deletion

Our data retention and deletion standard is published in full. It lists every place customer data lands, what deletes it, how each of those statements was verified, and what remains afterwards. Where a sink is covered by a test, the standard names the test; where a fact was read from the running system, it gives the reading and its date.

Deleting an account hard-deletes the account and everything it owns, together with its generated charts. A build-time check requires every table holding customer data to declare how it is deleted, so a new table cannot quietly escape the purge — and that check deliberately refuses to accept the database's own automatic cleanup as proof, because that mechanism does not fire in one of the two environments we run. Deletion also fails closed: if any storage system cannot be cleared, nothing is deleted anywhere, rather than the record disappearing while a copy survives elsewhere.

Three things the standard says plainly, because a summary that omitted them would read as coverage. Backups are frozen copies, so a customer deleted today still exists inside last night's copy until that copy expires; we cannot erase one customer from an archive and do not claim to. The lifetime of our offsite archives is not currently verified, and we publish no number for it until it is. And historical messages held by our email delivery vendor cannot be inspected or cleared at present, because that account has been suspended since June. Each of those is tracked as its own open item in the standard rather than described as handled.

Agent safety controls

Because the product runs autonomous expert agents, the safety question is not only "is the data encrypted" but "what can the agents do".

• A dedicated safety reviewer persona is a required participant on the panels that seat one, and a required participant's failure blocks synthesis rather than being averaged away. It is not seated on every panel, and its numeric weight is per-panel calibration rather than a gate — see Agent Safety Controls for exactly what is enforced and where each limit stops.
• A content filter applies to public-facing views.
• Escalations that need a person are routed into the platform's ticket system, so a human decision has a durable record rather than living in a chat log.
• Token and spend budgets are enforced per tier, which bounds the blast radius of a runaway agent loop in cost terms.
• Every state-changing operation an agent performs is recorded as metadata-only audit data — no prompt bodies or customer content in the audit record itself. See the coverage caveat above.

Availability and recovery

The application runs on a managed Linux host with PostgreSQL, fronted by Cloudflare. Automated database dumps run nightly and rotate on a seven-day window. Deployment migrations fail the release rather than being skipped, so a schema change cannot half-apply silently.

Stated plainly: an offsite copy does exist. Nightly archives are uploaded to storage in a separate cloud account, and have been for months — an earlier version of this page said there was no offsite copy at all, and that was wrong. Those uploads went unwatched for months, and when they stopped for twelve days across June and July 2026 nothing reported it; since 2026-08-22 an hourly check on the production host verifies that the offsite upload happened and records how long any outage has been running. What is still missing is the part that would make this a recovery capability. The check's alert reaches that host's login banner and no further, because no external alert destination is configured. No restore onto a replacement host has been demonstrated. So we publish no recovery point or recovery time objective, and we do not describe what we have as disaster recovery. Off-host alerting and a proven restore are both outstanding; see the roadmap.

Subprocessors

These are the third parties that can process customer data today, what each one is for, and what it is positioned to see. The list was built by enumerating our source code, our production configuration, our infrastructure, and the assets a visitor's browser loads.

Two entries need their real status stated rather than implied. Our database runs on the same host as the application, reachable only from that host — there is no separate managed-database provider in the path. Outbound email is currently not being delivered at all; the integration is configured but the account is suspended, so no message is reaching that vendor today. It is listed anyway, because restoring the account would resume delivery without any change to our code, and finding out about a subprocessor after the fact is precisely what this list exists to prevent.

Model providers. Platform-supplied inference goes to Anthropic. Our code supports ten further model providers, and none of them holds a credential in our production environment — so on our keys, your prompts reach one provider, not eleven. Enabling any of the others is an addition to this list and is governed by the notice below; it is not a configuration detail we would treat as internal. Separately, if you supply your own provider key, your prompts go to that provider under your contract — that is the one case where data reaches a provider not listed above, and it is your choice and your agreement rather than ours.

Notice before we add one. We will publish an addition to this table here, with the vendor, its purpose and what it will receive, at least 30 days before it begins processing customer data. We are deliberately not promising an email subscription: our outbound mail is suspended, and a notification channel that depends on a vendor we have listed as unavailable would not be a commitment worth making. A dated posting on this page is one we can keep unilaterally.

Stated plainly: we hold each of these vendors' standard commercial terms. We are not claiming a separately negotiated data processing agreement with any of them, because publishing that a vendor offers a DPA is not the same as our having signed one, and a subprocessor list is exactly the document where that distinction gets checked. This list also does not claim to be exhaustive: it states the four sweeps that produced it, and a third party reachable by some path those sweeps missed would not appear. Both gaps are open items on our side rather than wording we intend to leave standing.

We keep a fuller internal inventory behind this list — vendors that receive only operational data, third parties a visitor's browser contacts, and capabilities present in our code but not switched on — together with the evidence for each row. Ask and we will send it. This list is reviewed annually; it was last reviewed on 14 August 2026 and is next due 14 August 2027.

Roadmap

Dates below are our internal development plan. They are not contractual commitments, and if one slips we will say so rather than quietly restate it.

Reporting a vulnerability

Report security issues to [email protected], the address published in our security.txt. This page is the disclosure policy that file's Policy field points to.

In scope: meta-council.com and its subdomains, the public API and the hosted MCP endpoint. Out of scope: our subprocessors' own infrastructure (report those to them), findings from automated scanners with no demonstrated impact, and missing hardening headers with no exploitable consequence.

Please do not run denial-of-service or load tests, access or modify data belonging to another account, or use social engineering against our staff or subprocessors. Use your own account for testing. If a proof of concept would expose someone else's data, stop and describe the issue instead — we will take the write-up seriously without the demonstration.

What we commit to: we aim to acknowledge a report within five business days and to tell you what we plan to do about it. Meta Council is operated by a small team, so we would rather give you an honest timeline than a fast one we miss. We will credit you if you want the credit and stay quiet if you don't.

We do not currently run a paid bounty. We will not pursue or support legal action against someone who reports a genuine issue in good faith, stays within the scope above, and gives us a reasonable chance to fix it before disclosing it publicly.

Related: Privacy Policy · Terms of Service