# Universal authorisation > Powerful authorization policies follow your data, ensuring consistent protection everywhere your sensitive information flows. Source: https://orbitalhq.com/features/universal-authorisation ![](/assets/hero-04-universal-auth-C83XJq9e.webp) Universal authorisation # **Universal** data authorization **Write-once, enforce-everywhere**Define access policies once. Orbital enforces them consistently wherever your data is accessed - across APIs, databases, streams and MCP. [Get Started](/docs)[Read the docs](/docs/data-policies/data-policies) - ### Keep one set of rules One policy governs APIs, databases, streams and MCP. - ### Decide access on real context Make access decisions based on the caller, their role and claims, the request, and the data involved. - ### Mask fields, not whole responses Mask individual fields by caller and context - so agents get the data they need without exposing sensitive values. - ### Prove exactly what was accessed Trace every request from caller to response - including the systems accessed, policies applied, and where every returned value came from. ## Authorize by data type Define a rule for `DateOfBirth` once. Orbital enforces it whether the underlying field is `dob`, `date_of_birth` or `birthDate`, and whether the value comes from an API, database, stream or MCP response. [Read the docs](/docs/data-policies/data-policies) ![A policy applied to a response, showing which fields were returned in full, which were masked, and for whom.](/assets/policies-DaM1P9DW.svg) ## Write once. **Enforce everywhere.** - [ ### Field level enforcement Control access to individual types and fields. Mask, filter or deny sensitive data based on the caller and the context of the request. ](/docs/data-policies/data-policies) - [ ### Every source, every path The same rules are enforced across APIs, databases, Kafka streams, endpoints and MCP. ](/docs/data-policies/data-policies) - [ ### Policies as code Version, review and deploy policies from Git. A single change is applied consistently wherever the protected data is used. ](/docs/data-policies/data-policies) [View docs](/docs/data-policies/data-policies) ## Authorization **with real context** Policies can depend on more than roles and claims. Orbital can fetch the data needed to make an access decision — from team membership and entitlements to whether a customer has accepted the latest terms. **Decisions are evaluated against live data, at query time.** Give different roles different views of the same data. Managers can see the full record, while other users see only what their role allows. Mark a data type as sensitive once, and mask it consistently wherever it appears - in APIs, database results, streams and more. Serve different versions of the same event to different consumers. Managers can receive the full payload while restricted fields are removed for everyone else. Use live data from other systems when making an access decision. This policy blocks restricted records entirely, while masking sensitive fields for everyone else. policy.taxi ``` policy OnlyManagers against EmployeeInfo (user : User) -> { read { when { // Managers can see everything user.groups.contains('Manager') -> EmployeeInfo // Users can see everything except salary user.groups.contains('User') -> EmployeeInfo as { ... except { salary } } // Everyone else gets an error else -> throw((NotAuthorizedError) { message: 'Not Authorized' }) } }} ``` policy.taxi ``` // Define some PIItype FirstName inherits String, PIItype LastName inherits String, PII // Now secure it// Anything that serves PII data (API calls, db queries, kafka streams)// has this policy applied against itpolicy MaskPiiData against PII (user: User) -> { read { when { // Admins see everything: user.roles.contains('ADMIN') -> PII // ...otherwise mask it else -> concat(left(PII,3), '****') } }} ``` policy.taxi ``` // The eventmodel StockTradeEvent { symbol : Symbol price: Price customerName : CustomerName} // A policy to secure itpolicy FilterCustomerFromTrade against StockTradeEvent (user: User) -> { read { when { // Managers see everything user.roles.contains('MANAGER') -> StockTradeEvent // Everyone else has customer hidden else -> StockTradeEvent as { ... except { customerName } } } }} // Now stream it securelystream { StockTradeEvent } ``` policy.taxi ``` // Access Control Policy// Implements three-tier access:// 1. Managers: Full access to all trade data// 2. Restricted company trades: No access (filtered out)// 3. Standard users: Limited access with hidden customer and quantitypolicy FilterCustomerFromTrade against StockTradeEvent ( trade: StockTradeEvent, user: User, sensitiveCompanies: SensitiveCompanyList) -> { read { when { // TIER 1: Manager access - full visibility user.roles.contains('MANAGER') -> StockTradeEvent // TIER 2: Restricted company filter // Removes entire trade record if trading entity is classified sensitiveCompanies.companies.contains(trade.tradingEntity) -> null // TIER 3: Standard access // Shows trade but hides sensitive fields else -> StockTradeEvent as { ... except { tradingEntity, tradedQuantity } } } }} ``` [Try this example in the Taxi Playground](https://playground.taxilang.org/examples/policy-restricting-a-field)[Try this example in the Taxi Playground](https://playground.taxilang.org/examples/policy-on-base-type)[Try this example in the Taxi Playground](https://playground.taxilang.org/examples/kafka-role-based-auth)[Try this example in the Taxi Playground](https://playground.taxilang.org/examples/policy-rebac) ![](/assets/tane-D9exTJnJ.jpg) > Easily the best decision I’ve made was building our startup on Orbital. We got our platform built and operational in record time, with data pipelines and bespoke APIs for connecting our client data feeds. Tane Bellwood Co-founder - Musicflow ![](/assets/guillaume-rondy-B3dvCCtB.jpg) > The Orbital partnership was really easy. Their data platform made ingesting and performing complex data transformations simple. > > The team were great to work with, and were able to quickly enhance the platform where required to suit our use case. Guillaume Rondy VP, Global Head of Data - SimCorp ## Frequently asked questions Got another gnarly question? We’d love to hear it. Come and chat on [Slack](https://join.slack.com/t/orbitalapi/shared_invite/zt-697laanr-DHGXXak5slqsY9DqwrkzHg). Define rules against semantic data types rather than implementing them separately in each API, database or stream. A rule for DateOfBirth, for example, is evaluated wherever Orbital encounters that type - giving you one place to define the policy and consistent enforcement across every access path. The policy is based on the semantic type, not the field name. So dob, date\_of\_birth and birthDate can all be identified as DateOfBirth and governed by the same rules. Yes. Orbital can resolve additional data at query time and use it as part of the authorisation decision. That lets policies depend on things like entitlements, team membership, account status, or whether a customer has accepted the latest terms. Yes. Orbital works with OIDC-compatible identity providers and can use the caller’s identity, roles and claims when evaluating policy. Those details can also be combined with live data from your connected systems for more contextual access decisions. Add semantic types to the API and data schemas you already publish, then define your policies centrally. You do not need to recreate the same authorisation logic separately across every API, database, stream or MCP interface exposed through Orbital. ## **Secure your data**, wherever it comes from. Define a policy once. Orbital enforces it everywhere - every API, stream, store, and whatever comes next [Start for free](/docs)[Talk to us](/contact) ![](/assets/banner-cta-graph-axsXt434.webp)