Privacy Policy — plain English, engineer-grade detail.

01Overview & scope

EgisAI ("EgisAI", "we", "us") provides a runtime governance platform for AI agents and applications. Customers install our open-source Python SDK (egisai), point it at our control plane at app.egisai.co, and use the dashboard to define and review policies, audit traces, and behavioural signals across their AI traffic.

This policy explains what data we handle when you (a) visit our marketing pages, (b) sign up for and use the EgisAI dashboard, or (c) run an application that calls into the EgisAI SDK and forwards governance metadata to our control plane.

It does not govern data your application separately sends to upstream model providers (OpenAI, Anthropic, Google, AWS Bedrock, etc.). Those calls go directly to the provider; EgisAI is not in the network path for the model response payload itself.

02Roles: controller vs. processor

Our legal role depends on what you're doing with EgisAI:

• Account & marketing data (your dashboard email, name, organisation, marketing-page analytics) — EgisAI is the controller.
• Governance telemetry submitted by your SDK (audit events, redacted prompt previews, verdicts, end-user identifiers you choose to attach) — your organisation is the controller, EgisAI is the processor. We process this data on your instructions to operate the governance platform on your behalf.

If you require a written Data Processing Addendum (DPA) reflecting this split, email legal@egisai.co — we ship one on request and it is signed before any production rollout in regulated industries.

03What we collect

We try to be specific. Below is the actual list, organised by where the data comes from.

Account data (dashboard sign-up)

• Your work email and (optionally) display name.
• A salted password hash (we never store the password itself), or a Single Sign-On (SSO) identity from Google, Microsoft, or GitHub. For SSO we request the minimal scopes openid email profile only — never your inbox, drive, calendar, repos, etc.
• The organisation (workspace) name you create, and the role assigned to each member (owner / admin / member).
• Short-lived email verification codes for sign-up confirmation and password reset.
• Refresh-token records (hashed) bound to your browser session for stay-signed-in behaviour.

Operational metadata (dashboard usage)

• IP address and basic request metadata, used for rate-limiting, abuse prevention, and authentication audit (e.g. "this token was last used from this IP at this time").
• Server access logs (timestamp, route, status code, latency) retained for short windows for debugging and incident response.
• API keys you create for your SDK — stored as a SHA-256 hash, plus the first few characters of the prefix so you can identify them in the dashboard. The plaintext key is only visible at creation time and never persisted server-side.
• Your in-app onboarding state and notification preferences.

Governance telemetry (SDK → control plane)

Each time your application makes a governed AI call, the SDK emits an audit event to our control plane. Fields include:

• A trace identifier, your organisation id, agent id, and the SDK API key id that authenticated the call.
• The model provider (openai, anthropic, google, bedrock, …) and model name; status code; latency in milliseconds; whether the call was streamed; input/output token counts and an estimated USD cost.
• The policy verdict (allow / sanitize / block), the matched rule (if any), the rule's reason code, and the per-phase decision blocks (prompt_decision / response_decision).
• A bounded text preview of the request and (when applicable) the response — always sampled post-redaction (see Section 05). Detected PII has already been replaced with typed labels such as <SSN> or <EMAIL> before the preview is built.
• When a sanitize policy fired, a structured tally of the types found (e.g. "2 SSNs, 1 IBAN") and the mask shape used — never the original values, never reversible hashes.
• An auto-generated one-line natural-language summary of what the call attempted ("intent summary") for the dashboard timeline.
• Identity attributes your application chose to attach via set_context(): user id, user role, session id, workflow id, and (optionally) an opaque end_user_id. We hash end_user_id again on intake so even if your application accidentally sent a raw customer identifier, we don't persist it.
• Runtime fingerprint of the host process on first handshake (Python version, OS, framework versions, SDK version). No personal data.

Communications

Email content you send to hello@egisai.co, support@egisai.co, security@egisai.co, etc., is retained for support history and incident response.

Marketing-site analytics

Our marketing site (egisai.co) uses minimal first-party analytics to count visits and understand which pages perform — no cross-site advertising profiles, no third-party social trackers. If we add a richer analytics tool in future, this section will be updated and named explicitly.

04How we use it

We use the data above only for the following purposes:

• Operating the platform — authenticating you, enforcing policies, recording verdicts, surfacing anomalies, generating compliance evidence on your behalf.
• Maintaining security & integrity — preventing brute-force login, detecting abusive API key usage, investigating incidents.
• Improving the product — debugging issues, measuring feature adoption, prioritising the roadmap. Where this analysis touches governance telemetry, it is performed on your data only to serve your account, and any cross-customer analysis is performed on aggregated, non-identifying metrics (counts, latencies, verdict ratios).
• Communicating with you — sign-up flows, security alerts, billing notices, occasional product updates. Marketing emails always include an unsubscribe link and are off by default while we are in beta.
• Meeting legal obligations — responding to lawful requests, defending against legal claims, complying with applicable tax/audit rules.

We do not sell or rent personal data. We do not share governance telemetry with third parties for advertising, profiling, or training.

05Local-first redaction & minimisation

EgisAI was designed under one rule: raw regulated data must not leave the SDK boundary in clear form. We enforce that with a two-phase policy engine:

• Phase 1 (local, deterministic) runs entirely inside your process. It performs PII pattern detection (SSN, credit card, IBAN, email, phone, API-key-shaped strings, and operator-configured patterns), regex deny-lists, prompt-size caps, and model-allowlist checks. If Phase 1 blocks, the call is short-circuited; no LLM judge is consulted, no remote service is contacted.
• Phase 2 (remote, intent-oriented) consults our hosted semantic-guard judge only when Phase 1 has already allowed or sanitised the call. By the time the judge sees the prompt, detected PII has been replaced with typed labels (<SSN>, <EMAIL>, …), so the judge always operates on a data-clean copy.

The audit-event preview shipped to our control plane is sampled after redaction, so what you see on the dashboard reflects what the upstream model actually saw — never the pre-redaction original. Sanitisation tallies in the audit row record type and count only, never the raw value, and never a hash that could reverse it.

If the local PII engine errors mid-evaluation, the call is treated as if sensitive content was detected (we fail closed on PII). The product's general availability fail-open behaviour, documented in our Terms of Service, does not extend to letting raw PII through.

06No training on customer data

The one LLM call EgisAI makes on the governance path is the semantic-guard judge. That call goes to OpenAI's API under contractual terms that, as of the date of this policy, prohibit training on API inputs and outputs without opt-in. The data we send the judge has already been redacted by Phase 1 (see Section 05).

Auto-generated dashboard summaries (the one-line intent narrative) are produced on the same basis: a small model receives the already-redacted preview, returns a 220-character sentence, and the prompt/response pair is not retained for training.

07Retention & deletion

Governance telemetry retention is plan-bound:

Other data classes:

• Account & auth records — retained for the life of the account, plus a short window after deletion for billing reconciliation and abuse defence.
• Server access logs — short-lived (typically days, not months) and used only for debugging and security.
• Backups — encrypted, rotated, and overwritten on a rolling basis; deletion requests are honoured against live systems immediately and propagate through backups on the next rotation.
• Anonymous aggregate metrics — counts of governed calls, verdict ratios, latency distributions, and similar non-identifying numbers may be retained beyond the above horizons for product analytics.

Deletion & export

You can delete your workspace and request deletion of associated data at any time from the dashboard or by emailing privacy@egisai.co. We will confirm completion. Enterprise plans include bulk audit-log export for use in your own retention systems; ask your account contact or email sales@egisai.co.

08Subprocessors

We use a small, deliberately short list of subprocessors to operate EgisAI. We will give customers reasonable notice in this section before adding a new subprocessor that processes governance telemetry.

For an up-to-date machine-readable list, or to subscribe to subprocessor change notices, email legal@egisai.co.

09International data transfers

EgisAI is operated from the United States. If you access the service from outside the United States, your data will be transferred to and processed in the United States and any other country in which we or our subprocessors operate. Where required, we rely on the European Commission's Standard Contractual Clauses (SCCs) and equivalent UK / Swiss addenda to provide appropriate safeguards for cross-border transfers. A signed copy can be issued under the DPA on request.

10Security

We take security seriously because the integrity of this product is our customers' integrity. Highlights:

• Encryption in transit for all SDK-to-platform and dashboard-to-platform traffic (TLS 1.2+).
• Encryption at rest via the underlying database and storage providers.
• Secrets minimisation — SDK API keys are stored as SHA-256 hashes; passwords as salted hashes; refresh tokens hashed and bound to device.
• Access control — production access is restricted to a short list of named engineers, requires SSO + multi-factor authentication, and is reviewed periodically.
• Audit-row integrity — audit previews are sampled from the post-sanitisation snapshot, by design, so the row is an honest record of what shipped.
• Vulnerability disclosure — email security@egisai.co. We aim to acknowledge within 48 hours and follow a 90-day responsible-disclosure window by default. See the SDK's SECURITY.md.
• Incident response — if we determine that a security incident materially affects your data, we will notify the relevant workspace owner without undue delay and, where applicable, within statutory windows.

The platform is being built with SOC 2 / ISO 27001 / GDPR / HIPAA expectations in mind. We will publish certifications on the security page (docs.egisai.co/security) as they are issued; until then, please assume nothing on that list is formally certified.

11Your rights (GDPR / CCPA / similar)

Depending on where you live, you may have the right to:

• Access the personal data we hold about you.
• Correct inaccurate data.
• Delete data (subject to legal-hold exceptions).
• Export data in a portable format.
• Restrict or object to certain processing.
• Withdraw consent where we relied on consent.
• Opt out of "sale" or "sharing" (CCPA) — we do not sell or share personal data for cross-context behavioural advertising, so there is effectively nothing to opt out of.
• Lodge a complaint with your local data-protection authority.

To exercise these rights, email privacy@egisai.co from the address on your account, or have your workspace administrator make the request on your behalf. We will respond within the timeframes required by applicable law (typically within 30 days).

If your data is in the platform as part of your employer's workspace, your employer is the controller for that telemetry — please direct the request to them first. We will assist them in fulfilling it.

12Cookies & tracking

The dashboard uses:

• Strictly necessary cookies / local storage — to hold your access and refresh tokens so you stay signed in. Without these, the dashboard cannot function.
• No third-party advertising trackers.
• No cross-site profiling.

Marketing pages use minimal first-party analytics counts. Where required by law (e.g. EU/EEA visitors), we will surface a consent prompt before loading anything that would qualify as a non-essential cookie.

13Children

EgisAI is a B2B developer tool. It is not directed at children under 16, and we do not knowingly collect personal data from them. If you believe a child has provided us with personal data, please contact privacy@egisai.co so we can delete it.

14Changes to this policy

We may update this policy as the product evolves. Material changes will be flagged with a new "Effective" date at the top of this page, and — for material changes that affect existing telemetry handling — we will notify workspace owners by email before they take effect. Continued use of the platform after the effective date constitutes acceptance.

15Contact

Questions, requests, or comments:

• General privacy: privacy@egisai.co
• Security disclosures: security@egisai.co
• Legal / DPA / SCCs: legal@egisai.co
• Anything else: hello@egisai.co

Postal mail can be sent to EgisAI c/o the operating entity disclosed under the DPA. If you need a postal address before signing a DPA, email us and we'll provide it.