Preventing Data Leaks

Author – Kalana Jayasuriya, Software Engineer
Read time 5mts (word count 1,235)

As enterprises modernise their digital platforms, enterprise security is entering a new failure point - not authentication, but authorisation.

Authorisation logic is often deeply embedded inside applications, duplicated across services, and tightly coupled to business rules that change constantly. As systems scale across cloud platforms, internal tools, partner integrations, and increasingly AI-driven workflows  this approach becomes difficult to govern, costly to maintain, and risky to extend.

In most organisations, access decisions span multiple systems such as collaboration tools, data platforms, CRMs, internal APIs, and line-of-business applications. While authentication is usually centralised, authorisation is frequently hard-coded, inconsistent, or implemented differently in every application. This creates a growing risk of;

• Sensitive or restricted data being exposed unintentionally

• Inconsistent enforcement of access policies across systems

• Increased development and maintenance cost as rules evolve

• Slower innovation due to fear of breaking security controls

What's needed is a decoupled, fine-grained authorisation model that can express real-world relationships, evaluate access at runtime, and scale without forcing organisations into large, upfront platform investments.

This is where Relationship-based Access Graphs combined with Fine-Grained Authorisation (FGA) become critical. In this article, we explore how this model works in practice - and how open-source platforms like OpenFGA can deliver enterprise-grade security outcomes without the overhead of heavyweight, proprietary authorisation stacks.

OpenFGA offers a different path

As an open-source, production-ready fine-grained authorisation platform, OpenFGA enables enterprises to externalise and centralise access control. It allows organisations to model real-world relationships, evaluate access dynamically at runtime, and scale authorisation independently of application code.

In this article, we explore why relationship-based access control is becoming essential at enterprise scale and how OpenFGA provides a secure, flexible, and cost-effective foundation for modern authorisation, especially in an era of AI-driven systems and rapidly evolving business models.

For organisations looking to modernise identity and access control without unnecessary cost or complexity, this approach offers a practical, future-proof path forward.

Rethinking Access In Modern Enterprises

As enterprises grow more complex, access control is no more just a technical implementation detail it becomes a core governance and risk concern.

Modern organisations are fluid by design. Teams form around initiatives rather than fixed functions. External partners, vendors, and platforms require controlled access to shared systems. AI-driven workflows increasingly act on behalf of users. Yet many access models still assume static organisational charts and long-lived roles. This disconnect is where risk accumulates.

When access is defined primarily by ‘who someone is’ rather than ‘how they are connected to systems and data’, organisations are forced into trade-offs. To maintain speed, users are often over-permissioned. To maintain control, delivery slows as every organisational change requires reworking access logic. Over time, this creates brittle systems that are expensive to govern and difficult to evolve safely.

What’s needed is a way to express access in terms that reflect how enterprises actually operate dynamically, contextually, and at scale. This level of precision is critical in preventing over-permissioning, one of the leading causes of enterprise data exposure.

How Relationship-based Access Graph and FGA Are Connected

Relationship-based Access Graph and FGA are not separate ideas. They are co-existing with each other. Relationship-based Access Graph describes relationships, while FGA evaluates relationships at runtime. Without a Relationship-based Access Graph, FGA needs complex or hard-coded logic to make decisions. Without FGA, the Relationship-based Access Graph cannot create meaningful access control by itself.

• Relationship-based Access Graph is the model (How things are connected)

• FGA is the outcome (Can a specific user have permission to do a specific action on a selected resource)

Why Relationship-based Access Graph and FGA matter to the business

While all the business logic can stay in your system, you can move your Authorisation logic into an external and standard place.

‍

What is OpenFGA and why use it

OpenFGA is an open source authorisation engine that implements the Relationship-based Access Graph model to deliver Fine-Grain Authorisation (FGA). OpenFGA can provide a centralised, consistent way to define relationships and evaluate access decisions to multiple applications at once.

As an open source authorisation engine, OpenFGA answers all the burning problems currently in the industry. It is already

• Solved hard authorisation problems.

• Proved scalability and performance.

• Showed consistent behaviour across the system

• Lower maintenance costs and reduced security risks.

• Vendor-neutral and open standard.

• Provide Authorisation as infrastructure, not as application logic.

Real World Implementation

Assume you are implementing an AI model to connect with your Confluence. Now users can ask questions to AI, and AI can go through all the resources in your Confluence.

Problem -: If a normal user requests a detail that belongs to an admin user or a restricted page, the AI model can retrieve that data for that normal user. We need to prevent that from happening

Answer -: OpenFGA

How to do that?

1. Create Authorization Model
2. Build Tuples (Relationships defined here)
3. Implement authorization inside the AI model

Create Authorization Model

When we build the OpenFGA model for Confluence, we consider four entities.

1. Members
2. Groups
3. Pages
4. Spaces

These four entities have the following relations

• A member can exist as a single entity or part of a group.
  • Alice is a member
  • Alice is assigned to group A
• A group can be created using two or more members.
• A space is where we can create pages. Spaces can be viewed by individual members or groups
  • Bob can view space A
  • Group A can view Space A
• Pages are the children of space. Pages can be viewed by individual members or groups. However if both entities should have access to the parent space if they need to view the page.
  • Group A can view Space A, then they can view the pages inside Space A as well.
  • Bob can view Space A, then they can view the pages inside Space A as well.
• We can restrict access to an individual page in a space. In that scenario, entities who has access to view space may not be able to view restricted pages. Only mentioned entities can view that particular page.
  • Page A in Space A is restricted. Alice is the one on the allow list
  • Bob and Group A can also view Space A, but they don’t have permission to view Page A. Only Alice can.

We have applied these logics internally, and the diagram below describes the above logics

1. User: Tharindu (as “Group: Kodez Admins”)
   • Space: MHFA
     • Page: Details
     • Page: Restricted Page
2. User: Dilan (as an Individual)
   • Space: MHFA
     • Page: Details
3. User: Dilan (as an Individual)
   • Space: Angle Auto
     • Page: Auth0 Integration
     • Page: Support Contacts
4. User: Kalana (as an Individual)
   • Space: MHFA
     • Page: Details
     • Page: Restricted Page
5. User: Kalana (as Group: “Managed Services”)
   • Space: Angle Auto
     • Page: Auth0 Integration
     • Page: Support Contacts

To support this, we need to create a matching authorization Model. Let’s discuss this step by step.

1. Define base entity. In our case, members are defined by this.

type user

2. Define Group. The group can have members.

type group
  relations
    define member: [user]

• Users can be assigned a member relationship in a group

3. Define space. Users and Groups can view

type space
  relations
    define viewer: [user, group#member]

• define viewer: [user, group#member] -: User can be a viewer of the space
• define viewer: [user, group#member] -: User can be a member of s group that is a viewer of the space

4. Define page. Page is the child of space

type page
  relations
    define parent: [space]
    define viewer: viewer_direct and viewer_inherited
    define viewer_direct: [user, group#member]
    define viewer_inherited: viewer from parent

• parent: [space] -: A page has a parent space.
• viewer_direct: [user, group#member] -: A page can be viewed directly by a user or a group member.
• viewer_inherited: viewer from parent -: Inherits viewer permissions from its parents space.
• viewer: viewer_direct and viewer_inherited -: A user can view a page if they are a direct viewer and if they inherit view permission from the parent space.

model
  schema 1.1

type user

type group
  relations
    define member: [user]

type space
  relations
    define viewer: [user, group#member]

type page
  relations
    define parent: [space]
    define viewer: viewer_direct and viewer_inherited
    define viewer_direct: [user, group#member]
    define viewer_inherited: viewer from parent

‍

‍Example scenario

Build Tuples (Sample)

const fga = new OpenFgaClient({
  apiUrl: process.env.FGA_API_URL,
  storeId: process.env.STORE_ID,
});

const writeTuples = async () => {
  await fga.write({
    writes: [
      // Assign roles
      { user: 'user:Kalana', relation: 'viewer', object: 'role:admin' },
      { user: 'user:Dilan', relation: 'viewer', object: 'role:member' },

      // Role's readers granted access to pages
      { user: 'role:admin#reader', relation: 'viewer_direct', object: 'page:Restricted_Page' },
      { user: 'role:admin#reader', relation: 'viewer_direct', object: 'page:Page_Details' },
      { user: 'role:member#reader', relation: 'viewer_direct', object: 'page:Page_Details' },
    ],
  });
};

writeTuples();

Implement authorization

const fga = new OpenFgaClient({
  apiUrl: process.env.FGA_API_URL,
  storeId: process.env.STORE_ID,
});

const checkAccess = async (user, page) => {
  const result = await fga.check({
    user: `user:${user}`,
    relation: 'viewer_direct',
    object: `page:${page}`,
  });

  console.log(`${user} can view ${page}: ${result.allowed ? 'Yes' : 'No'}`);
};

(async () => {
  await checkAccess('Kalana', 'Restricted_Page');
  await checkAccess('Dilan', 'Restricted_Page');
  await checkAccess('Kalana', 'Page_Details');
  await checkAccess('Dilan', 'Page_Details');
})();

Output

Kalana can view Restricted_Page: Yes
Dilan can view Restricted_Page: No <---- check success
Kalana can view Page_Details: Yes
Dilan can view Page_Details: Yes

‍

Key Takeaway

For enterprise technology leaders, authorisation is no longer a purely technical concern, it is a governance, risk, and scalability challenge.

As organisations expand across platforms, partners, and AI-enabled services, access decisions must be precise, auditable, and adaptable to constant change. Hard-coded rules, fragmented policies, and proprietary platforms make this harder, not easier to achieve.

OpenFGA demonstrates that enterprise-grade authorisation does not need to come with enterprise lock-in. By separating access control from application logic and modelling permissions through relationships rather than static roles, OpenFGA enables to;

• Prevent AI-driven data leaks

• Enforce least-privilege access across complex hierarchies

• Adapt instantly to organisational change

• Centralise authorisation without disrupting delivery teams

Perhaps most importantly, OpenFGA aligns with how modern enterprises actually operate where people, services, data, and AI systems are connected through dynamic relationships that change over time.

As organisations reassess their security architecture for the next phase of growth, open, relationship-based authorisation is becoming a strategic requirement. OpenFGA offers a practical, proven way to meet that requirement without sacrificing flexibility, transparency, or control.

At Kodez, we help enterprises design and implement identity-led authorisation architectures that scale across cloud platforms, internal systems, and AI-powered applications. Whether integrating OpenFGA, Auth0, or modern cloud identity platforms, our focus is ensuring security, delivery velocity, and governance evolve together.