Your organization decides before the model does.

Access is limited by the system, not by prompts.

Two independent enforcement layers

Access scope is enforced both in the database and in server-side tool authorization. One layer allowing something does not remove the other layer's check. Every endpoint checks the request again.

Out-of-scope information is not visible

An object a user cannot reach is not simply an object that will not open. For that request it is not treated as existing. A chat held by someone on the finance team cannot reach Human Resources data. The reason is not an instruction given to the model: the information never enters that request's scope.

The narrowest rule applies

Rules at the organization, team, project, object, and action level are evaluated together. Where they conflict, the narrower access rule is applied.

Team policies can only narrow

A team can narrow the access and data policies the organization defines. It cannot widen or weaken the organization's ceiling.

When a permission is removed, new access stops

Authorization is evaluated again on every new request. When a user's permission is removed, fetching new information stops from the next request onward. Records of operations that already happened are not changed retroactively.

Background jobs run under their own identity

Agents, scheduled jobs, and other background processes run under the service identities defined for them. They do not automatically inherit the wider access scope of the admin who created them.

DLP and prompt masking

Sensitive data is checked before the model

DLP checks are not applied only to the prompt a user writes. Documents fetched from connected data sources, integration outputs, agent contexts, and automation inputs pass through the same policies.

Organizations set their own sensitive data rules

Organizations can define which data types may be processed freely, which must be masked, and which may not be sent to particular model routes. These policies can be narrowed by team, project, intended use, and model route.

Prompt masking reduces data exposure

Prompt masking lets an operation continue without sending the original values of personal information, customer data, trade secrets, and other sensitive fields the organization has defined. Masking does not replace access control: the user must first have permission to reach the information, and then pass the data policies.

DLP stops the request when required

Not every use of sensitive data continues with masking. Organization policy can require that certain content is processed by no model at all, or used only on EU-hosted routes.

Records fall under the same protections

Masking content on the way to the model and then keeping it in the clear in the audit record is not accepted. Audit records, context, and results are held under the relevant access, DLP, and retention policies.

Where data is stored, where it is processed

Retention and inference are managed separately

Where workspace data is kept and where model inference happens are treated as separate boundaries in Feza. Feza is being built to keep workspace data in the European Union. Model inference can happen in the European Union, or on a route beyond it that the organization has approved, according to organization policy, data class, and the route chosen.

A route that stays entirely in the European Union

When EU-hosted models are used, both workspace data and model inference stay inside the European Union. This route is built for customers who do not want their data to leave the Union, who prefer local processing under organization policy, or who can process certain data classes in one jurisdiction only.

Approved cross-border route

For the data and use cases organization policy allows, inference can be carried out over an approved model route beyond the European Union. On this route workspace data stays in the European Union. Only the content permitted for that request, masked where required, is sent to the chosen model.

The same organization can use both routes

An organization does not have to pick one model route for all its requests. General internal content can be processed on an approved route beyond the Union while sensitive data is sent to EU-hosted models. Data classes that are barred are sent to no model at all.

The boundary is visible before sending

The model, provider, and processing region to be used are set before the request is sent. The route that actually ran is then added to the audit record. "Approved route" here means a route allowed under organization policy. It does not mean a certification from a regulatory body.

A claim to stay in the EU is verified end to end

A model server sitting inside the European Union is not on its own enough to say that inference stays there. No route is published as a "route that stays in the European Union" until the model infrastructure, the content sent, the audit records, and the related data flow have all been verified.

Model routes

A route is not just a model name

Every route is a durable Feza object defined by a model, a provider, a processing region, the data classes allowed, and the use policies in force.

The rules are independent of the provider

Organization policies are not built around the features of one model provider. Even when the model in use changes, the access, DLP, prompt masking, and record rules keep being applied.

No silent fallback

A request that has to stay in the European Union is not sent automatically to a model outside it when the local route is unavailable. In the same way, a route that does not meet the boundary the organization approved is not quietly swapped for another provider or region. The request stops and the situation is shown to the user.

No model is trained on customer content

Feza does not use customer content to train its own models. This is not a certification or a marketing badge. It is Feza's own commitment about how that content is used. The data use terms of external model providers are evaluated route by route and presented where the organization can see them.

Governance and admin controls

Roles and memberships are managed in one place

Users, team memberships, roles, access boundaries, and model policies are managed at the organization level.

The same rules hold across the workspace

Using chat, an agent, an automation, a project, a skill, or an integration does not change the security model. The same identity, access, DLP, and model route rules are applied across the whole Feza workspace.

Integrations do not gain unlimited access

An integration being connected does not mean every user can reach all the data in that system. Integration actions are limited by the scope of the user, the team, the project, and the service identity.

High-impact operations can be tied to approval

Human approval can be made mandatory for actions that change data, send to an external system, or produce a result for the organization. An agent proposing an operation is kept separate from the operation being carried out.

The records themselves are permissioned

An audit record is not opened to a wider audience than the chat, project, or automation it belongs to. What the record contains falls under the relevant masking and data retention policies.

Risks specific to AI

Prompt injection is treated as a default risk

Feza assumes the model can be steered by a document, an email, or web content it reads. Fetched content is labeled as data, not as instruction. The model carries no credentials. Every tool call is re-authorized on the server against the user's real access scope.

Prompt masking and prompt injection are not the same thing

Prompt masking reduces how much sensitive data is exposed to the model. Prompt injection controls are applied against fetched content steering the system or its tools. Feza treats the two risks as separate security layers.

A model cannot grant permission on its own

A model proposing an operation or producing a tool call does not create the permission to carry it out. Permission always comes from Feza's server-side identity and policy layer.

Current trust status

Feza publishes only the trust claims that can be verified.

Certification

No information security standard or certification is claimed. A certification will be published here only after its scope and validity have been verified.

Independent review

No completed third-party security review or penetration test is claimed for the product as it stands.

Regulatory compliance

No general or unconditional claim of compliance is made for any jurisdiction. An organization's data type, intended use, model route, provider, and contractual structure must be evaluated separately.

Availability

Without a measured and published service level in place, no availability rate or SLA is claimed.

File security

File type validation, quarantine, and malicious content scanning are among the launch conditions. Until these controls are verified, it will not be claimed that they are operational.

Performance and capacity

Without representative measurements in place, no figures for speed, volume, file size, accuracy, or language quality are published.

Legal documents

Privacy policy

The current text is a draft and has not been through review by a lawyer. Read the privacy policy.

Terms of use

The current text is a draft and has not been through review by a lawyer. Read the terms of use.

Data processing agreement

Data processing terms are set out in a separate agreement for each customer and use case. That agreement is not published as general site text.

Imprint

Trade register, representation, and contact details are published on the imprint page. View the imprint.