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.
- No SOC 2 report. Neither Type I nor Type II. No independent examination has been performed. Readiness work is scheduled, and we will not describe ourselves as SOC 2 compliant, certified, or audited until an examination is complete and a report exists.
- No HIPAA Business Associate Agreement. Meta Council is not HIPAA-ready. Protected health information (PHI/ePHI) must not be submitted to the platform. This is an absolute limit, not a preference.
- No third-party penetration test report is currently available to share.
- No enterprise single sign-on and no enforced multi-factor authentication. Access today is email and password.
- No customer-facing audit-log export. We keep internal audit records, but you cannot yet pull them into your own SIEM.
- Backups are not yet stored offsite, and restoring onto a replacement host has not been demonstrated. Nightly database dumps run and rotate on the production host; that is a real control but it is not a disaster recovery capability, and we do not describe it as one.
- Audit coverage is partial. Application audit records exist and are metadata-only, but strict transactional coupling between a state change and its audit record currently covers 4 of 110 registered state-changing operations. Treat the audit trail as incomplete until that number is 110.
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| Control | What you should see |
|---|---|
| Transport security | TLS terminated at the edge; HSTS with a one-year
max-age and includeSubDomains; upgrade-insecure-requests
in the content security policy. |
| Content Security Policy | A restrictive policy with
frame-ancestors 'none', object-src 'none',
base-uri 'self' and form-action 'self'. |
| Clickjacking and sniffing | X-Frame-Options: DENY and
X-Content-Type-Options: nosniff. |
| Referrer leakage | Referrer-Policy:
strict-origin-when-cross-origin. |
| Browser capability lockdown | A Permissions-Policy that denies camera, microphone, geolocation, payment, USB, serial, MIDI, motion sensors and browsing topics. |
| Vulnerability disclosure | A published security.txt naming [email protected] as the reporting address. |
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
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.
Platform-supplied models
When you use platform-supplied inference instead, prompts are sent to a third-party model provider under our contract with them. We are publishing a per-provider breakdown of exactly what each provider is contractually permitted to do with prompt content, including retention windows and training use. Until that page is published, ask us and we will answer for the specific provider your deployment would use rather than give a blanket assurance here.
We do not train models on customer content. Meta Council does not build or fine-tune models from your prompts, outputs, or documents.
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 carrying double weight on most panels. It is not optional per-run configuration.
- 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: nightly local dumps are not disaster recovery. There is no offsite copy today and no demonstrated restore onto a replacement host, so we publish no recovery point or recovery time objective. Both are in progress; see the roadmap.
Subprocessors
We are compiling and will publish a complete list of every third party that can process customer data, with the purpose and region for each, together with a subscribable notice of changes. Until that list is published, ask and we will provide the current inventory directly.
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.
| Work | Target |
|---|---|
| Published subprocessor list, pre-answered security questionnaire, per-provider model data-handling terms, customer-facing agent audit export, proven offsite restore | September 2026 |
| Enterprise SSO with enforced MFA; human approval that shows the concrete action, target and data before an agent proceeds | October 2026 |
| Workspace role-based access control; demonstrated end-to-end deletion across every storage sink; third-party penetration test report | December 2026 |
| SOC 2 examination | Scoping decision pending. We will publish a date only once a CPA firm is engaged and the scope is agreed. |
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