IMMERSIVE COMMONS/ FT10

Security · Scope · Reporting · Safe harbor

Found something?
Tell us.

The policy target for our security.txtfile, and the real process behind it — not boilerplate. Written from the code, not a template. If a claim below stops matching how the system actually behaves, it's a bug — tell us.


→ scope→ reporting→ safe harbor→ the auth model→ what we don't claim

§ 01 · Scope

A community platform, not a regulated SaaS.

Immersive Commons is a members-run space at Frontier Tower, Floor 10, San Francisco — not a multi-tenant SaaS handling regulated personal data. Our threat model reflects that.

  1. 01In scope. Unauthorized access to member-only data; a lower tier or an agent token reaching a capability its scope shouldn't grant; credential or token leakage; abuse that exhausts a shared resource (rate limits, quotas); accidental exposure of an internal system to the public Internet.
  2. 02Not in scope. Sophisticated targeted attacks against IC specifically (we're not a high-value target and don't need you to prove that point); insider threats from operators, who have full admin by design; treating IC as a system of record for regulated personal data under a compliance framework — see /privacy§06 for why that framework doesn't apply here.

§ 02 · Reporting

One email. No public issue.

Do not file a public GitHub issue or post a finding anywhere public before we've had a chance to look at it. Email admin@immersivecommons.com with what you found, how you found it, and what it would take to reproduce. That address is our current published security contact — the same one listed in security.txt — and it is not a dead inbox: it also carries our community and press mail, and operators route security reports from it to whoever needs to act. (A dedicated security@ alias is the intended next step — this line moves to it the day it exists.)

A reasonable response window is about 48 hours for acknowledgement. A fix timeline depends on severity — Immersive Commons is a community platform without a paid security program, not a vendor with a contractual SLA. If you don't hear back in a reasonable time, following up is fine; we'd rather get a nudge than have a real report sit unread.

§ 03 · Safe harbor

Good-faith research won't get you in trouble.

If you're testing in good faith, report what you find promptly, and stay within these bounds, we won't pursue legal action over the testing itself:

  1. 01Don't access, modify, or exfiltrate another member's data beyond what's needed to demonstrate the issue.
  2. 02Don't degrade or disrupt the service for other members — no load-testing, no automated scanning at a volume that looks like an attack from the other side.
  3. 03Give us a reasonable window to fix the issue before any public disclosure, and coordinate the disclosure with us first.

This is a good-faith undertaking from a small community platform, not a formal legal bug-bounty program — we don't currently pay out bounties, and this page isn't a substitute for your own legal judgment. If you're unsure whether something you want to try falls inside these bounds, ask first at the address above.

§ 04 · The auth model

What you're actually poking at.

Two identity paths, both anchored in Clerk: a browser session cookie for humans, and an agent token (agt_*) for AI agents acting on a member's behalf. An agent token can only be minted with a signed-in human's approval — nothing self-mints one — and it carries a scope list narrower than the account's tier entitlements. The server never stores a token's plaintext, only a SHA-256 digest; the plaintext is shown once, at mint time, and is unrecoverable after that. Full detail on tiers, scopes, and the dual-auth gate is public at /auth.md and /privacy§§02–03 — that's the real contract, not a summary of one kept elsewhere.

§ 05 · What we don't claim

No compliance theater, no bounty theater.

We don't claim GDPR, CCPA, HIPAA, or SOC 2 compliance, a contractual uptime SLA, or a paid bug-bounty program with published payouts — none of that matches what this project actually is. What we do claim is real: a channel that reaches a person, a response window we intend to hit, and a safe-harbor commitment we mean. If any of that changes — if IC grows into something that needs a formal program — this page gets rewritten before the claim changes, not after.