Security
The claims are only as good as the controls behind them.
Privacy that depends on a promise is fragile. Discrezo is designed around technical boundaries, encryption, restricted access and continuous verification so the privacy model does not rely on someone simply choosing not to look.
This page explains the controls behind Discrezo, the threats we design against, and where our assurance work actually stands.
ISO/IEC 27001 certified
No vague promises. No pretending security work is ever finished.
ISO/IEC 27001
Certified
Formal information-security management framework.
Privacy boundaries
Designed into the architecture
Identity and conversation content have different paths.
Automated testing
Built into delivery
Critical privacy boundaries are checked continuously.
Independent review
Product-specific review scheduled
Separate from ISO 27001 certification.
The security model
Different parts of the system are allowed to know different things.
Discrezo's privacy architecture depends on limiting what each part of the service can access. Security exists to preserve those boundaries.
Account
Can handle
- Account
- Subscription
- Billing relationship
Does not need
- Readable prompts
- Readable answers
Inference
Can handle
- Prompt
- Relevant context
- Model response
Does not need
- Discrezo account identity
- Account email
- Payment identity
Encrypted history
Can hold
- Encrypted conversation data
- Encrypted memory
Does not have
- The key required to read it
Nobody needs the whole picture.
Security principles
Separation
Identity and inference have different responsibilities.
Minimum access
Every component should receive only what it needs to do its job.
Encryption
Saved conversation content is encrypted before sync.
Verification
Important boundaries are tested rather than assumed.
ISO/IEC 27001 provides the security-management framework around these controls. The Discrezo architecture adds product-specific technical boundaries on top.
Controls
What is enforced, not merely intended.
Provider credentials stay server-side
AI provider credentials are never shipped to the browser.
Credentials used to access AI providers are held within protected server-side systems. They can be rotated, disabled and constrained without exposing them inside the user application.
A browser session should never contain credentials capable of spending against Discrezo's provider accounts.
Prompt bodies do not belong in logs
Operational logging is designed without a place for the conversation.
Discrezo needs telemetry to know whether the service is healthy. It does not need a second copy of your conversation to do that.
- Latency
- Model route
- Token usage
- Error category
- Provider status
- Prompt body
- Response body
- Readable conversation history
Automated checks are designed to catch changes that would introduce prohibited data into operational logging.
Account identity does not travel with AI requests
The AI request does not need your Discrezo identity.
The inference path is designed so unnecessary account and client-identifying information is removed before requests reach AI providers.
- Account ID
- Account email
- Payment identity
- Originating network identity
The provider receives what it needs to answer the question, not the Discrezo identity belonging to the person who asked it.
Access is deliberately narrow
Different systems have different jobs.
Account management, inference and encrypted history are deliberately separated responsibilities. Access is limited around those responsibilities rather than giving every part of the product access to everything.
The safest data is often data a component never receives.
Security checks run with the build
Privacy boundaries are treated as testable requirements.
Automated checks look for security problems including leaked secrets, vulnerable dependencies and violations of critical privacy boundaries.
Security tests support human review. They do not replace it.
Your saved conversations
The key that opens your history is not ours.
Saved conversations and memory are encrypted on trusted user devices before they are synced. Discrezo can store the encrypted data needed for sync without holding the key required to read it.
Your device
Readable conversation
Encrypt
On your trusted device
Sync
Encrypted data only
Discrezo
Stores encrypted data. Cannot decrypt it.
You can read your history.
Discrezo cannot.
We do not claim that nothing is stored. Saved content is encrypted before sync and Discrezo does not hold the key required to read it.
Two very different types of keys
Provider credentials
Stay inside protected Discrezo server-side systems.
Your conversation encryption key
Stays with your trusted devices.
The credentials that let Discrezo call an AI provider belong on our infrastructure. The key that lets someone read your saved conversations does not.
The primary privacy boundary
Who paid and what was asked should not become the same record.
One of the most important security goals in Discrezo is preventing ordinary operation from creating a durable relationship between account identity and readable AI requests.
Account side
- Who has access
- Plan entitlement
- Subscription
Readable question
AI side
- Question
- Context
- Answer
Discrezo identity
Discrezo knows who, not what.
The AI side knows what, not who.
Observability
Know whether the service is healthy without reading the conversation.
Running a reliable AI service requires telemetry. The security objective is to collect operational information without creating a shadow conversation database in the logs.
We need to know
- Latency
- Route health
- Token volume
- Errors
- Service availability
We do not need
- Prompt bodies
- Response bodies
- Readable history
- Account identity inside inference logs
If a sensitive field does not need to exist, the safest implementation is not to collect it.
AI providers
A good model is not automatically an approved route.
Model quality is only one requirement. A provider also has to meet the privacy and security requirements of the route being used.
Provider eligibility
Only approved provider configurations can receive Discrezo traffic.
Request hygiene
AI requests should contain the content needed for inference, not unrelated identifying account information.
Mode enforcement
Private Mode changes which providers are eligible before ordinary model selection occurs.
A new model being excellent is not enough. The route still has to satisfy the security rules.
Private means the router cannot quietly change its mind.
When Private Mode is enabled, provider eligibility is constrained before quality ranking. The request cannot fall back to OpenAI, Anthropic or Google simply because one of those models would otherwise rank higher.
Security constraints outrank model preference.
The router
Your prompt is input. It is not authority.
The router has to inspect the nature of a request to decide which eligible AI should answer it. The prompt itself must never be able to override the rules controlling where it is allowed to go.
Privacy rules first
Provider restrictions are applied before quality selection.
Prompts are untrusted
The contents of the request cannot grant themselves additional routing permission.
Fail safe
A routing failure must not silently weaken the privacy mode selected by the user.
A prompt can influence which eligible model is best. It cannot decide which security rules apply.
Abuse controls
Privacy still has to survive real-world abuse.
A consumer AI service has to defend against automated resale, stolen credentials, runaway usage and attempts to turn an account into an uncontrolled API.
Rate controls
Reduce automated abuse and service exhaustion.
Plan limits
Constrain unexpected or excessive usage.
Provider spend protection
Limits reduce the impact of compromised credentials or abnormal traffic.
The objective is to control abuse without attaching a persistent customer identity to every inference request.
Threat model
What we assume will eventually be tested.
A useful threat model assumes that important boundaries will be attacked, bypassed accidentally, or weakened by future changes.
Account-to-prompt correlation
Can somebody recreate who asked what?
This is the central privacy threat. The system is designed so account identity is not part of the ordinary AI inference path and readable conversation content does not belong on the account side.
Log leakage
Could debugging quietly create a conversation archive?
Logging is treated as part of the privacy boundary. Prompt and response bodies should not have a legitimate place in operational schemas.
Metadata leakage
Could identity reach an AI provider without being obvious?
Outbound AI requests are treated as a security boundary. Only information required for inference should travel downstream.
Secret theft
What if a provider credential is exposed?
Provider credentials remain server-side and are subject to rotation, monitoring and usage controls designed to reduce the blast radius of compromise.
Your conversation encryption key is not part of that server-side credential estate because Discrezo does not hold it.
Router manipulation
Can a malicious prompt escape a routing restriction?
Security and provider-eligibility rules take precedence over instructions inside the prompt.
Payment fraud and resale
Can consumer access become an uncontrolled commercial API?
Usage and allowance controls exist to make automated abuse and runaway consumption harder.
Client compromise
What happens if the device itself is compromised?
Your trusted device is one place where your conversations legitimately exist in readable form. Malware, browser compromise or someone with access to that device can therefore undermine protections that are working correctly elsewhere.
Supply-chain risk
What if code we depend on becomes unsafe?
Dependencies and deployment changes are part of the attack surface and are included in security review and automated scanning.
Verification
Boundaries deserve tests.
A privacy rule written in documentation can drift. A privacy rule backed by automated checks is harder to violate unnoticed.
Logging
Tests check that prohibited conversation fields are not introduced into operational logging.
AI requests
Tests check that account and unnecessary client identity do not appear in provider-bound requests.
Encrypted sync
Tests check that readable conversation or memory content is not written into sync storage.
Secrets and dependencies
Changes are checked for exposed credentials and vulnerable dependencies.
Automated tests support review.
They do not replace human security judgement.
Incident response
Have the plan before something goes wrong.
A security incident is the wrong time to decide who does what. Discrezo's security programme includes defined incident procedures and the ability to restrict provider routing quickly when required.
Contain
Problematic routes can be disabled.
Restrict
Traffic can be constrained to approved healthy providers.
Revoke
Compromised provider credentials can be disabled and replaced.
Communicate
Material security incidents should be communicated clearly.
Independent assurance
ISO/IEC 27001 certified.
Discrezo operates an ISO/IEC 27001-certified information security management system.
ISO 27001 gives us a formal framework for identifying information-security risks, assigning controls, reviewing those controls and continually improving how security is managed across the organisation.
Risk management
Security risks are formally identified, assessed and treated.
Access control
Access to systems and information is governed through defined responsibilities.
Incident management
Security events are managed through established processes.
Continual improvement
Controls are reviewed as the product and threat environment change.
Certification matters.
It does not replace secure architecture.
ISO 27001 provides assurance over the information-security management system within its certified scope. Discrezo's product-specific privacy architecture still requires technical controls, testing and specialist review of its own.
Product assurance
The architecture gets reviewed too.
In addition to ISO/IEC 27001 certification, the Discrezo product architecture is scheduled for an independent security review focused on its critical security and privacy boundaries before broad paid launch.
That review is separate from ISO 27001 certification and is not yet complete.
Assurance status
Where we actually stand.
Assurance item
Status
ISO/IEC 27001
Certified
Security architecture and threat modelling
Part of the launch programme
Privacy-boundary automated testing
Part of the launch programme
Provider privacy configuration verification
Required before launch
Product-specific independent security review
Scheduled, not yet complete
Public security documentation
In progress
Public service status page
Planned for launch
ISO 27001 provides independent assurance over our information-security management framework. The product-specific review adds scrutiny of the Discrezo architecture itself.
Security research
Found something? Tell us.
A coordinated vulnerability disclosure process will be available before public launch, including a monitored contact route and acknowledgement of reports received.
We support good-faith security research and will not threaten researchers who act responsibly.
What security does not mean
No responsible system is described as unbreakable.
Your own words
If you type your name, employer, address or other identifying information into a prompt, the AI provider processing it can read those words.
Your device
A compromised device can expose information that is legitimately decrypted on that device.
Network observation
Discrezo does not claim to make the fact that you connected to the service invisible to every possible network observer.
Standard-mode providers
In Standard Mode, an approved AI provider processes the content required to answer your question. Provider security remains part of the overall risk model.
Software vulnerabilities
No certification, encryption scheme or architecture makes software impossible to compromise. Controls reduce risk and limit access. They do not eliminate risk.
We'd rather state a limit clearly than hide it behind the word “secure”.
Questions
Questions worth asking.
Yes. Discrezo operates an ISO/IEC 27001-certified information security management system.
Security by design
Trust the controls.
Then verify them.
ISO/IEC 27001-certified security management. Product-specific separation, encryption and testing. No claim that security work is ever finished.
Founding members lock $8/month for life. No card required.
Privacy is the architecture.
Security is what keeps that architecture true.