How Eunomia works

Eunomia is a standalone authorization server that can be integrated into any application. It follows a client-server architecture where the server handles all authorization logic, while clients interact with it through a REST API or available SDKs.

schema

Architecture Overview

Eunomia uses a decoupled architecture consisting of two main components:

Server: A standalone service that manages authorization policies, storing metadata for principals and resources, and making access control decisions. The server is built on top of Open Policy Agent (OPA) and exposes a REST API.
Client: A component integrated into your application that communicates with the Eunomia server. You can interact with the server either directly through HTTP requests or by using one of the provided SDKs for a more streamlined experience.

Authorization Workflow

Working with Eunomia involves two distinct phases:

Policy Configuration Phase

In this phase, you configure the authorization policies that will govern access control in your application based on principals and resources attributes.

For example, you might register an AI agent as a resource with its capabilities as metadata, and register users as principals with their roles and departments as metadata.

Policy Enforcement Phase

At runtime, your application enforces the configured policies by:

Access Checks: Sending access check requests to the Eunomia server
Policy Evaluation: The server retrieves the metadata for entities given and evaluates it against the defined policies.
Authorization Decision: The server returns a boolean result indicating whether access should be granted or denied.

Eunomia components

Eunomia enables developers to create Policies that determine whether Principals can access specific Resources based on their Attributes. These four core concepts — Policies, Principals, Resources, and Attributes — form the foundation of Eunomia's authorization model. Principals and Resources are both categorized as Entities.

Let’s analyze each one individually.

Policies

Policies, which are the rules that determine whether Principals can access specific Resources. The policies are stored and accessed whenever necessary. By default, we deny access, so any allowed behavior must be explicitly defined in the policy.

Principals

Principals encompass humans, AI agents, or a combination thereof. The term is consistently plural to represent the chain of actors involved in a given action. This could range from a simple human database query to a complex interaction where a human engages with an agent that consults another, which then queries a database. The potential complexity of such chains is evident.

Enforcing restrictions across the entire Principal chain is crucial, even when the final Principal executes the action. Access privileges are inherently intertwined within these chains.

Resources

Resources, akin to Principals, are Entities. They can be Data, Tools, or AI agents, representing what a specific list of Principals seeks to access. When AI agent access requires regulation, they function as Resources, enabling control by humans or other AI agents.

The Resource concept is particularly crucial as, unlike legacy authorization tools focused on static resources, it extends to Tools and AI agents,providing the opportunity for a fundamentally new approach to what Principals can access.

Attributes

Attributes are metadata associated with Entities, forming the basis for Policy creation by determining Principal access to specific Resources.

Attributes can be registered at configuration time or shared at runtime. Attributes encompass a broad range of elements. These may include human Principal roles, AI agent metadata, agent output shared at runtime or even inputs from external tools.

User Guides

Guide	Description	Jump to
Run the Eunomia Server	Learn how to configure and run the Eunomia server	Page
Create a Policy	Learn how to create policies	Page
Register an Entity	Learn how to register entities	Page
Update and Delete an Entity	Learn how to update or delete entities	Page
Check Access at Runtime	Learn how to check access at runtime	Page