From 442ea88b9874ca9b42e604d80342fcc606fa7450 Mon Sep 17 00:00:00 2001 From: Andres Aguiar Date: Wed, 1 Apr 2026 16:50:45 -0400 Subject: [PATCH 1/4] feat: first version of AuthZ for Agents docs --- docs/content/modeling/agents/overview.mdx | 28 +++ .../agents/task-based-authorization.mdx | 229 ++++++++++++++++++ docs/sidebars.js | 17 ++ 3 files changed, 274 insertions(+) create mode 100644 docs/content/modeling/agents/overview.mdx create mode 100644 docs/content/modeling/agents/task-based-authorization.mdx diff --git a/docs/content/modeling/agents/overview.mdx b/docs/content/modeling/agents/overview.mdx new file mode 100644 index 0000000000..ad3a72c352 --- /dev/null +++ b/docs/content/modeling/agents/overview.mdx @@ -0,0 +1,28 @@ +--- +id: overview +title: 'Authorization for Agents' +slug: /modeling/agents +sidebar_position: 0 +description: Authorization patterns for AI agents and automated processes +--- + +import { CardGrid, DocumentationNotice, IntroCard, ProductName, ProductNameFormat } from '@components/Docs'; + + + +This section presents authorization patterns for AI agents and automated processes using . + + + + diff --git a/docs/content/modeling/agents/task-based-authorization.mdx b/docs/content/modeling/agents/task-based-authorization.mdx new file mode 100644 index 0000000000..e0f152b206 --- /dev/null +++ b/docs/content/modeling/agents/task-based-authorization.mdx @@ -0,0 +1,229 @@ +--- +title: Task-Based Authorization +description: Modeling task-based authorization for agents +sidebar_position: 1 +slug: /modeling/agents/task-based-authorization +--- + +import { + DocumentationNotice, + ProductName, + ProductNameFormat, + RelatedSection, +} from '@components/Docs'; + +# Modeling Task-Based Authorization for Agents + + + +Agents need credentials to interact with APIs. These can be user or service credentials, for internal or third-party systems. In most cases, those permissions grant agents broad access to the system, as the authorization services that issue credentials for those APIs do not support granting fine-grained permissions. Consent prompts and service credentials are too coarse. + +Task-Based Authorization is an emerging authorization pattern designed to grant agents (such as AI systems or automated processes) access to perform specific actions only when necessary, without granting permanent permissions. The core principle is to avoid granting agents permanent access to perform actions, instead restricting their capabilities to the exact tasks they are explicitly authorized to execute. Agents start with zero permissions. + +For example, rather than allowing an agent to create tickets across all projects, you might configure it to perform the task "Create a ticket on project X" — limiting its permissions to a specific context. Agents operate within the constraints of the tasks they are assigned, meaning they cannot act independently unless their task explicitly includes the required permissions. + +This approach enhances security by ensuring permissions are scoped to specific tasks, reducing the risk of unintended actions. By aligning authorization with actionable goals, Task-Based Authorization provides granular control over agent behavior while maintaining flexibility in task execution. + +## A simple model + +Below is a very simple version of an model that represents tool authorization for a [Model Context Protocol](https://modelcontextprotocol.io/) server. You have a set of tools, and when a task starts, you write the tuples that grant the task the permissions to call the tools it needs. + +```dsl.openfga +model + schema 1.1 + +type task +type tool + relations + define can_call: [task] +``` + +That works, but it's not much better than using a database table with task/operation/resource. To leverage the benefits of you'd want to model a resource hierarchy where permissions can be inherited. + +## Tool hierarchy + +A slightly more interesting model includes a tool hierarchy. In the model below, you can configure permissions per tool resource. We are also adding that certain tools can be set to be called by any task. + +```dsl.openfga +model + schema 1.1 + +type task + +type tool + relations + define can_call: [task, task:*] + +type tool_resource + relations + # this would be sent as a contextual tuple + define tool: [tool] + define can_call: [task] or can_call from tool +``` + +## Domain-specific models + +The example above models a generic tool-calling domain. If you are building a generic authorization model for any tool, it can work. However, if you are building your own agents for your own application, the model should reflect the application's domain. Let's take a model for a simple project management system and adjust it to handle tasks: + +```dsl.openfga +model + schema 1.1 + +type user + +type task + +type organization + relations + define admin: [user] + define member: [user] + +type project + relations + define organization: [organization] + define owner: [user] + define member: [user] + define read: [task] + define write: [task] + define delete: [task] + define can_delete: delete or owner or admin from organization + define can_edit: write or owner or admin from organization + define can_read: read or can_edit or member from organization + define can_create_ticket: can_edit + +type ticket + relations + define project: [project] + define owner: [user] + define read: [task] + define write: [task] + define delete: [task] + define can_delete: owner or delete or can_delete from project + define can_edit: owner or write or can_edit from project + define can_read: read or write or can_read from project +``` + +In this case, we are enriching the user-oriented model that we already had, and adding `task` as a principal. You can now decide to give a `task` permissions to `write` a project. That will include permissions to read/edit the project and edit/read all the project tickets. Or you can decide to grant permissions at the ticket level instead. This enables you to make your applications ready for agent authorization with little effort. + +## Session and agent-level permissions + +Imagine you are creating an interactive agent, where the user can create many sessions, and you want the ability to grant permissions at the session level. When the user grants a permission, you can give them the option to do it "for this session". + +Back to our simple model to illustrate the concept, we can add a `session` type, where we add all the tasks for the session, and we grant permissions to `session:1#task`. That implies that any task linked to the session will be able to call the tool: + +```dsl.openfga +model + schema 1.1 + +type task + +# A client session. Tasks are members of a session. +type session + relations + define task: [task] + +type tool + relations + define can_call: [task, session#task] +``` + +You can use a similar approach if you want the user to allow the agent to always perform the calls. We assign the tasks to the agent and write a tuple saying "all the tasks for this agent can call this tool": + +```dsl.openfga +model + schema 1.1 + +type task + +type agent + relations + define task: [task] + +# A client session. Tasks are members of a session. +type session + relations + define task: [task] + +type tool + relations + define can_call: [task, session#task, agent#task] +``` + +## Expiration and turn count + +You can use [conditions](../../configuration-language.mdx#conditions) to model time-based or turn-based expiration for task permissions. + +```dsl.openfga +model + schema 1.1 + +type task + +type tool + relations + define can_call: [task, task with expiration, task with turn_count] + +condition expiration(grant_time: timestamp, grant_duration: duration, current_time: timestamp) { + current_time < grant_time + grant_duration +} + +condition turn_count(turns_granted: int, current_turn: int) { + current_turn <= turns_granted +} +``` + +## Binding agents to tasks + +In the examples above, there wasn't a way to verify that the agent making the call was actually assigned to the task being executed. We can use contextual tuples to send the agent that is making the call and verify it's actually linked to the task. This is a scenario similar to [Organizational Context](../modeling/organization-context-authorization.mdx). + +```dsl.openfga +model + schema 1.1 + +type task + +type agent + relations + define task: [task] + +type tool + relations + define agent_in_context: [agent] + define can_call: [task] and task from agent_in_context +``` + +### Delegating task permissions to sub-agents + +In the same way agents start with zero permissions, sub-agents will too. If you want to delegate work to a sub-agent, you have two options: + +- You ask the sub-agent to keep working on the same task, assign the task to the sub-agent too, and inherit all the permissions it can perform. +- You further restrict the permissions and create a new task with just what the sub-agent can do. + +## Identifying permissions required per task + +This is the fun part! It's not trivial, and there's a lot of research going on to map user intent to permissions. Some documents that explore the topic: + +- [Intent-Based Access Control: Securing Agentic AI Through Fine-Grained Authorization](https://ibac.dev/) +- [Delegated Authorization for Agents Constrained to +Semantic Task-to-Scope Matching](https://arxiv.org/abs/2510.26702) +- [The Mission Shaping Problem](https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/) +- [Securing Agentic AI: authorization patterns for autonomous systems](https://dev.to/siddhantkcode/securing-agentic-ai-authorization-patterns-for-autonomous-systems-3ajo) + + +## Related Sections + + diff --git a/docs/sidebars.js b/docs/sidebars.js index e7f963f7de..fca1cf6e4d 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -309,6 +309,23 @@ const sidebars = { }, ], }, + { + type: 'category', + collapsed: true, + collapsible: true, + label: 'Authorization for Agents', + link: { + type: 'doc', + id: 'content/modeling/agents/overview', + }, + items: [ + { + type: 'doc', + label: 'Task-Based Authorization', + id: 'content/modeling/agents/task-based-authorization', + }, + ], + }, { type: 'category', collapsed: true, From c60112192ae2a7ab80ac7780005a4ec6ce816e6a Mon Sep 17 00:00:00 2001 From: Andres Aguiar Date: Wed, 1 Apr 2026 23:56:00 -0400 Subject: [PATCH 2/4] feat: rewrite based on claude's suggestions --- .../agents/task-based-authorization.mdx | 200 +++++++++++++----- 1 file changed, 142 insertions(+), 58 deletions(-) diff --git a/docs/content/modeling/agents/task-based-authorization.mdx b/docs/content/modeling/agents/task-based-authorization.mdx index e0f152b206..dcd53df186 100644 --- a/docs/content/modeling/agents/task-based-authorization.mdx +++ b/docs/content/modeling/agents/task-based-authorization.mdx @@ -18,31 +18,13 @@ import { Agents need credentials to interact with APIs. These can be user or service credentials, for internal or third-party systems. In most cases, those permissions grant agents broad access to the system, as the authorization services that issue credentials for those APIs do not support granting fine-grained permissions. Consent prompts and service credentials are too coarse. -Task-Based Authorization is an emerging authorization pattern designed to grant agents (such as AI systems or automated processes) access to perform specific actions only when necessary, without granting permanent permissions. The core principle is to avoid granting agents permanent access to perform actions, instead restricting their capabilities to the exact tasks they are explicitly authorized to execute. Agents start with zero permissions. +Task-Based Authorization grants agents access to perform specific actions only when necessary, without permanent permissions. Agents start with zero permissions and receive only what a given task requires. For example, rather than allowing an agent to create tickets across all projects, you authorize it to "Create a ticket on project X" — scoping permissions to a specific context. -For example, rather than allowing an agent to create tickets across all projects, you might configure it to perform the task "Create a ticket on project X" — limiting its permissions to a specific context. Agents operate within the constraints of the tasks they are assigned, meaning they cannot act independently unless their task explicitly includes the required permissions. +This guide shows how to model task-based authorization in , progressing from a basic tool-calling model to patterns that support permission hierarchies, session scoping, expiration, and agent binding. -This approach enhances security by ensuring permissions are scoped to specific tasks, reducing the risk of unintended actions. By aligning authorization with actionable goals, Task-Based Authorization provides granular control over agent behavior while maintaining flexibility in task execution. +## Tool authorization -## A simple model - -Below is a very simple version of an model that represents tool authorization for a [Model Context Protocol](https://modelcontextprotocol.io/) server. You have a set of tools, and when a task starts, you write the tuples that grant the task the permissions to call the tools it needs. - -```dsl.openfga -model - schema 1.1 - -type task -type tool - relations - define can_call: [task] -``` - -That works, but it's not much better than using a database table with task/operation/resource. To leverage the benefits of you'd want to model a resource hierarchy where permissions can be inherited. - -## Tool hierarchy - -A slightly more interesting model includes a tool hierarchy. In the model below, you can configure permissions per tool resource. We are also adding that certain tools can be set to be called by any task. +The simplest model represents tool authorization for a [Model Context Protocol](https://modelcontextprotocol.io/) server. When a task starts, you write tuples granting it permission to call the tools it needs. ```dsl.openfga model @@ -56,14 +38,52 @@ type tool type tool_resource relations - # this would be sent as a contextual tuple define tool: [tool] define can_call: [task] or can_call from tool ``` +A `tool` represents a capability (e.g. `slack_send_message`), and a `tool_resource` represents a specific target within that tool (e.g. a Slack channel). Granting `can_call` on a `tool` automatically grants access to all its resources. You can also grant access to individual resources, or use `task:*` to allow any task to call a tool. + +For example, you can grant `task:1` access to send any Slack message, while restricting `task:2` to a specific channel: + +```yaml +tuples: + # Any task can list Slack channels + - user: task:* + relation: can_call + object: tool:slack_list_channels + + # task:1 can send any Slack message + - user: task:1 + relation: can_call + object: tool:slack_send_message + + # task:2 can only send messages to channel XGA14FG + - user: task:2 + relation: can_call + object: tool_resource:slack_send_message/XGA14FG +``` + +When checking whether `task:2` can call `tool_resource:slack_send_message/XGA14FG`, send a [contextual tuple](../../interacting/contextual-tuples.mdx) linking the resource to its tool: + +```yaml +tests: + - tuples: + - user: tool:slack_send_message + relation: tool + object: tool_resource:slack_send_message/XGA14FG + check: + - user: task:1 + object: tool_resource:slack_send_message/XGA14FG + assertions: + can_call : true +``` + +This avoids storing a tuple for every channel — you provide the tool-to-resource relationship at query time. + ## Domain-specific models -The example above models a generic tool-calling domain. If you are building a generic authorization model for any tool, it can work. However, if you are building your own agents for your own application, the model should reflect the application's domain. Let's take a model for a simple project management system and adjust it to handle tasks: +The model above is generic. If you are building agents for your own application, the authorization model should reflect your application's domain. Consider a project management system: ```dsl.openfga model @@ -81,11 +101,17 @@ type organization type project relations define organization: [organization] + + # relations for users define owner: [user] define member: [user] + + # relations for tasks define read: [task] define write: [task] define delete: [task] + + # permissions for users define can_delete: delete or owner or admin from organization define can_edit: write or owner or admin from organization define can_read: read or can_edit or member from organization @@ -95,6 +121,8 @@ type ticket relations define project: [project] define owner: [user] + + # relations for tasks define read: [task] define write: [task] define delete: [task] @@ -103,13 +131,11 @@ type ticket define can_read: read or write or can_read from project ``` -In this case, we are enriching the user-oriented model that we already had, and adding `task` as a principal. You can now decide to give a `task` permissions to `write` a project. That will include permissions to read/edit the project and edit/read all the project tickets. Or you can decide to grant permissions at the ticket level instead. This enables you to make your applications ready for agent authorization with little effort. +Here we enrich an existing user-oriented model by adding `task` as a principal. Granting a `task` the `write` relation on a project gives it permission to read/edit the project and all its tickets. You can also grant permissions at the ticket level for more granular control. This makes your application ready for agent authorization with minimal changes to your existing model. -## Session and agent-level permissions +## Scoping permissions to sessions and agents -Imagine you are creating an interactive agent, where the user can create many sessions, and you want the ability to grant permissions at the session level. When the user grants a permission, you can give them the option to do it "for this session". - -Back to our simple model to illustrate the concept, we can add a `session` type, where we add all the tasks for the session, and we grant permissions to `session:1#task`. That implies that any task linked to the session will be able to call the tool: +In interactive agents, users may create multiple sessions. You can scope permissions to a session so that granting access applies to all tasks within it. You can also scope permissions to an agent, so they persist across sessions. ```dsl.openfga model @@ -117,41 +143,46 @@ model type task -# A client session. Tasks are members of a session. +type agent + relations + define task: [task] + type session relations define task: [task] type tool relations - define can_call: [task, session#task] + define can_call: [task, session#task, agent#task] ``` -You can use a similar approach if you want the user to allow the agent to always perform the calls. We assign the tasks to the agent and write a tuple saying "all the tasks for this agent can call this tool": - -```dsl.openfga -model - schema 1.1 +The `can_call` relation accepts three types of assignments: -type task +- `task` — grant permission to a specific task. +- `session#task` — grant permission to all tasks in a session. When the user says "allow this for this session", write a tuple like `user: session:1#task, relation: can_call, object: tool:slack_send_message`. +- `agent#task` — grant permission to all tasks for an agent, across sessions. When the user says "always allow this", write a tuple with `agent:1#task` instead. -type agent - relations - define task: [task] +Each task is linked to its session and agent when created: -# A client session. Tasks are members of a session. -type session - relations - define task: [task] +```yaml +tuples: + # Link task to its agent and session + - user: task:1 + relation: task + object: agent:1 + - user: task:1 + relation: task + object: session:1 -type tool - relations - define can_call: [task, session#task, agent#task] + # Grant session-level access + - user: session:1#task + relation: can_call + object: tool:slack_send_message ``` ## Expiration and turn count -You can use [conditions](../../configuration-language.mdx#conditions) to model time-based or turn-based expiration for task permissions. +You can use [conditions](../../configuration-language.mdx#conditions) to make permissions expire after a duration or a number of agent turns. ```dsl.openfga model @@ -172,9 +203,35 @@ condition turn_count(turns_granted: int, current_turn: int) { } ``` +The `expiration` condition grants access for a fixed duration from the grant time. The `turn_count` condition grants access for a fixed number of agent turns. When writing the tuple, you provide the condition parameters: + +```yaml +tuples: + # task:1 can call the tool for 10 minutes + - user: task:1 + relation: can_call + object: tool:slack_send_message + condition: + name: expiration + context: + grant_time: "2026-03-22T00:00:00Z" + grant_duration: 10m + + # task:2 can call the tool for 2 turns + - user: task:2 + relation: can_call + object: tool:slack_send_message + condition: + name: turn_count + context: + turns_granted: 2 +``` + +When checking access, pass the current time or turn number in the request context. + ## Binding agents to tasks -In the examples above, there wasn't a way to verify that the agent making the call was actually assigned to the task being executed. We can use contextual tuples to send the agent that is making the call and verify it's actually linked to the task. This is a scenario similar to [Organizational Context](../modeling/organization-context-authorization.mdx). +The examples above don't verify that the agent making the call is actually assigned to the task. You can enforce this using [contextual tuples](../../interacting/contextual-tuples.mdx) and an intersection (`and`) in the model, similar to the [Authorization Through Organization Context](../organization-context-authorization.mdx) pattern. ```dsl.openfga model @@ -192,24 +249,51 @@ type tool define can_call: [task] and task from agent_in_context ``` +The `can_call` relation requires both that the task has been granted access **and** that the agent making the call is linked to the task. When the task is created, link it to its agent: + +```yaml +tuples: + - user: task:1 + relation: task + object: agent:1 + - user: task:1 + relation: can_call + object: tool:slack_send_message +``` + +At check time, send a contextual tuple identifying the calling agent: + +```yaml +tests: + - tuples: + - user: agent:1 + relation: agent_in_context + object: tool:slack_send_message + check: + - user: task:1 + object: tool_resource:slack_send_message/XGA14FG + assertions: + can_call : true +``` + +If a different agent tries to use `task:1`, the check will return `false` because the agent-to-task link won't match. + ### Delegating task permissions to sub-agents -In the same way agents start with zero permissions, sub-agents will too. If you want to delegate work to a sub-agent, you have two options: +Sub-agents also start with zero permissions. When delegating work, you have two options: -- You ask the sub-agent to keep working on the same task, assign the task to the sub-agent too, and inherit all the permissions it can perform. -- You further restrict the permissions and create a new task with just what the sub-agent can do. +- **Share the task**: assign the same task to the sub-agent, giving it all the task's permissions. +- **Restrict further**: create a new task with a narrower set of permissions for the sub-agent. -## Identifying permissions required per task +## Further reading -This is the fun part! It's not trivial, and there's a lot of research going on to map user intent to permissions. Some documents that explore the topic: +Mapping user intent to the right set of permissions is an active area of research. These resources explore the topic: - [Intent-Based Access Control: Securing Agentic AI Through Fine-Grained Authorization](https://ibac.dev/) -- [Delegated Authorization for Agents Constrained to -Semantic Task-to-Scope Matching](https://arxiv.org/abs/2510.26702) -- [The Mission Shaping Problem](https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/) +- [Delegated Authorization for Agents Constrained to Semantic Task-to-Scope Matching](https://arxiv.org/abs/2510.26702) +- [The Mission Shaping Problem](https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/) - [Securing Agentic AI: authorization patterns for autonomous systems](https://dev.to/siddhantkcode/securing-agentic-ai-authorization-patterns-for-autonomous-systems-3ajo) - ## Related Sections Date: Thu, 2 Apr 2026 00:29:23 -0400 Subject: [PATCH 3/4] fix: applied feedback --- blog/fine-grained-news-2026-01.md | 98 +++++++++++++++++++ .../agents/task-based-authorization.mdx | 81 +++++++++------ 2 files changed, 149 insertions(+), 30 deletions(-) create mode 100644 blog/fine-grained-news-2026-01.md diff --git a/blog/fine-grained-news-2026-01.md b/blog/fine-grained-news-2026-01.md new file mode 100644 index 0000000000..284f94c705 --- /dev/null +++ b/blog/fine-grained-news-2026-01.md @@ -0,0 +1,98 @@ +--- +title: Fine-Grained News - January 2025 +description: Fine-Grained News +slug: fine-grained-news-2026-01 +date: 2026-01-23 +authors: aaguiar +tags: [newsletter] +image: https://openfga.dev/img/og-rich-embed.png +hide_table_of_contents: false +--- +# Fine-Grained News - February 2026 + +Welcome to OpenFGA's Fine-Grained News, New year edition! + +## 🎉 OpenFGA to CNCF Incubation! + +## 🚀 What We've Shipped + +### OpenFGA v1.11.0 Performance Improvements + +Starting with [OpenFGA v1.10.0](https://github.com/openfga/openfga/releases/tag/v1.10.0), we've included a query planner that selects resolution strategies based on runtime statistics, behind the `enable-check-optimization` flag. The planner can pick different strategies per-relation, and we've seen significant improvements in performance for some models/relations. In-depth engineering blog post coming soon! + +https://auth0.com/blog/self-tuning-strategy-planner-openfga/ + +Check Optimization Blog + +### Write Endpoint Enhancements + +In case you missed it, we also included in [v1.10.0](https://github.com/openfga/openfga/releases/tag/v1.10.0) two new (optional) parameters to the [`/write`](https://openfga.dev/api/service#/Relationship%20Tuples/Write) endpoint that allow specifying the expected behavior when duplicated tuples are written or non-existing tuples are deleted. The Go, Java, and .NET SDK already support them, and we'll be completing support for Python, and Javascript in the next few weeks. + +### AuthZen v1.0 Experimental + +### SDK & Tooling Updates + +- [OpenFGA Skills for AI Agents](https://github.com/openfga/agent-skills) are a set of skills that help coding agents create authorization models and implement OpenFGA. Install them with: + +``` +npx skills add https://github.com/openfga/agent-skills +``` + +and then ask your agent: + +``` +/openfga create an authorization model for +``` + +- [Go SDK 0.7.3](https://github.com/openfga/go-sdk/releases/tag/v0.7.3) adds support +- [.NET SDK 0.8.0](https://github.com/openfga/dotnet-sdk/releases/tag/v0.8.0) adds +- [Java SDK 0.9.2](https://github.com/openfga/java-sdk/releases/tag/v0.9.2) adds +- [Python SDK 0.9.7](https://github.com/openfga/python-sdk/releases/tag/v0.9.7) adds +- [CLI 0.7.5](https://github.com/openfga/cli/releases/tag/v0.7.5) + + - bug fix for writing with 403s? + - fix when importing > 100 assertions? + +## 🌟 OpenFGA in Action + +We started a new + +# OpenFGA in Action Schedule + +OpenFGA in action is a new segment in the [OpenFGA community meeting](https://github.com/openfga/community/blob/main/community-meetings.md) where different companies or open source projects share why and how they implemented OpenFGA. + +You can see the presentations from Jeremy Loy from Headspace and Sarah Funkhouser from OpenLane. + +We are planning next year's content, if you are interested in presenting please add yourselves to he list [here](https://github.com/openfga/community/openfga-in-action.md)! + +## 🌟 Community Spotlight + +[Read.AI](https://read.ai/), one of the earliest OpenFGA adopters, [was recognized by OpenAI for processing 1 trillion tokens](https://www.linkedin.com/posts/readinc_huge-shout-out-to-this-crew-and-all-read-activity-7384229591386783744-noSI). They use OpenAI for RAG use cases powered by OpenFGA :). + +Congrats to [Luke Woloszyn](https://www.linkedin.com/in/lukewoloszyn/), [Andrew Powers](https://www.linkedin.com/in/andrew-powers-geo/), and [Sam Matthews](https://www.linkedin.com/in/mapsam/) for such a great achievement! + +- Hierarchy of Needs? +- AuthZ for MCPs? + +## 📣 Community Updates & Events + +### Recent Talks & Content + +- [Carla Urrea](https://www.linkedin.com/in/carlastabile/) published [a LinkedIn Course about OpenFGA en Español](https://www.linkedin.com/learning/openfga-implementacion-de-fine-grained-authorization/que-es-openfga-y-por-que-usarlo) and a blog post about [Understanding ReBAC and ABAC Through OpenFGA and Cedar](https://auth0.com/blog/rebac-abac-openfga-cedar/). A repository with the examples used in the blog post is [here](https://github.com/openfga/openfga-cedar-comparison). + +- [Deepu K Sasidharan](https://www.linkedin.com/in/deepu05/) presented about [Delay the AI Overlords: How OAuth and OpenFGA Can Keep Your AI Agents from Going Rogue](https://www.youtube.com/watch?v=-V251N-pYYI) at DevOxx. + +- KubeCon links: + +### Upcoming Events - KubeCon Europe + +- [Andres Aguiar](https://www.linkedin.com/in/aaguiar/) from Okta will be presenting at KubeCon Europe, together with [Erica Hughberg](https://www.linkedin.com/in/alicejgibbons/) from Tetrate about [Design Patterns for Consistent Centralized Authorization](https://kccncna2025.sched.com/event/27Fek). Great chance to see [OpenFGA and Envoy](https://www.cncf.io/projects/envoy/) working together! + +- [Andres Aguiar](https://www.linkedin.com/in/tylernix/) from Okta will host the OpenFGA Project Lightning talk [OpenFGA: Google Zanzibar Style Authorization Made Developer-Friendly](https://kccncna2025.sched.com/event/27d4i). + +OpenFGA will also have a kiosk at the KubeCon Project Pavilion during all afternoons. + +## **See you soon!** + +Fine-Grained News is published monthly. If you have any feedback, want to share your OpenFGA story, or have a noteworthy update, please let us know on any of our [community channels](https://openfga.dev/community) or at [community@openfga.dev](mailto:community@openfga.dev). + diff --git a/docs/content/modeling/agents/task-based-authorization.mdx b/docs/content/modeling/agents/task-based-authorization.mdx index dcd53df186..ff51ec4e99 100644 --- a/docs/content/modeling/agents/task-based-authorization.mdx +++ b/docs/content/modeling/agents/task-based-authorization.mdx @@ -6,6 +6,7 @@ slug: /modeling/agents/task-based-authorization --- import { + CheckRequestViewer, DocumentationNotice, ProductName, ProductNameFormat, @@ -64,22 +65,23 @@ tuples: object: tool_resource:slack_send_message/XGA14FG ``` -When checking whether `task:2` can call `tool_resource:slack_send_message/XGA14FG`, send a [contextual tuple](../../interacting/contextual-tuples.mdx) linking the resource to its tool: +When checking whether `task:2` can call `tool_resource:slack_send_message/XGA14FG`, send a [contextual tuple](../../interacting/contextual-tuples.mdx) linking the resource to its tool. This avoids storing a tuple for every channel — you provide the tool-to-resource relationship at query time. -```yaml -tests: - - tuples: - - user: tool:slack_send_message - relation: tool - object: tool_resource:slack_send_message/XGA14FG - check: - - user: task:1 - object: tool_resource:slack_send_message/XGA14FG - assertions: - can_call : true -``` - -This avoids storing a tuple for every channel — you provide the tool-to-resource relationship at query time. + ## Domain-specific models @@ -182,7 +184,7 @@ tuples: ## Expiration and turn count -You can use [conditions](../../configuration-language.mdx#conditions) to make permissions expire after a duration or a number of agent turns. +You can use [conditions](../../configuration-language.mdx#conditional-relationships) to make permissions expire after a duration or a number of agent turns. ```dsl.openfga model @@ -261,22 +263,41 @@ tuples: object: tool:slack_send_message ``` -At check time, send a contextual tuple identifying the calling agent: +At check time, send a contextual tuple identifying the calling agent. If the agent is linked to the task, the check returns `true`: -```yaml -tests: - - tuples: - - user: agent:1 - relation: agent_in_context - object: tool:slack_send_message - check: - - user: task:1 - object: tool_resource:slack_send_message/XGA14FG - assertions: - can_call : true -``` + + +If a different agent tries to use `task:1`, the check returns `false` because the agent-to-task link won't match: -If a different agent tries to use `task:1`, the check will return `false` because the agent-to-task link won't match. + ### Delegating task permissions to sub-agents From b8af7b31fcf319d37e41e8c8306868282225594c Mon Sep 17 00:00:00 2001 From: Andres Aguiar Date: Thu, 2 Apr 2026 05:52:32 -0400 Subject: [PATCH 4/4] fix: removed FGN --- blog/fine-grained-news-2026-01.md | 98 ------------------------------- 1 file changed, 98 deletions(-) delete mode 100644 blog/fine-grained-news-2026-01.md diff --git a/blog/fine-grained-news-2026-01.md b/blog/fine-grained-news-2026-01.md deleted file mode 100644 index 284f94c705..0000000000 --- a/blog/fine-grained-news-2026-01.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Fine-Grained News - January 2025 -description: Fine-Grained News -slug: fine-grained-news-2026-01 -date: 2026-01-23 -authors: aaguiar -tags: [newsletter] -image: https://openfga.dev/img/og-rich-embed.png -hide_table_of_contents: false ---- -# Fine-Grained News - February 2026 - -Welcome to OpenFGA's Fine-Grained News, New year edition! - -## 🎉 OpenFGA to CNCF Incubation! - -## 🚀 What We've Shipped - -### OpenFGA v1.11.0 Performance Improvements - -Starting with [OpenFGA v1.10.0](https://github.com/openfga/openfga/releases/tag/v1.10.0), we've included a query planner that selects resolution strategies based on runtime statistics, behind the `enable-check-optimization` flag. The planner can pick different strategies per-relation, and we've seen significant improvements in performance for some models/relations. In-depth engineering blog post coming soon! - -https://auth0.com/blog/self-tuning-strategy-planner-openfga/ - -Check Optimization Blog - -### Write Endpoint Enhancements - -In case you missed it, we also included in [v1.10.0](https://github.com/openfga/openfga/releases/tag/v1.10.0) two new (optional) parameters to the [`/write`](https://openfga.dev/api/service#/Relationship%20Tuples/Write) endpoint that allow specifying the expected behavior when duplicated tuples are written or non-existing tuples are deleted. The Go, Java, and .NET SDK already support them, and we'll be completing support for Python, and Javascript in the next few weeks. - -### AuthZen v1.0 Experimental - -### SDK & Tooling Updates - -- [OpenFGA Skills for AI Agents](https://github.com/openfga/agent-skills) are a set of skills that help coding agents create authorization models and implement OpenFGA. Install them with: - -``` -npx skills add https://github.com/openfga/agent-skills -``` - -and then ask your agent: - -``` -/openfga create an authorization model for -``` - -- [Go SDK 0.7.3](https://github.com/openfga/go-sdk/releases/tag/v0.7.3) adds support -- [.NET SDK 0.8.0](https://github.com/openfga/dotnet-sdk/releases/tag/v0.8.0) adds -- [Java SDK 0.9.2](https://github.com/openfga/java-sdk/releases/tag/v0.9.2) adds -- [Python SDK 0.9.7](https://github.com/openfga/python-sdk/releases/tag/v0.9.7) adds -- [CLI 0.7.5](https://github.com/openfga/cli/releases/tag/v0.7.5) - - - bug fix for writing with 403s? - - fix when importing > 100 assertions? - -## 🌟 OpenFGA in Action - -We started a new - -# OpenFGA in Action Schedule - -OpenFGA in action is a new segment in the [OpenFGA community meeting](https://github.com/openfga/community/blob/main/community-meetings.md) where different companies or open source projects share why and how they implemented OpenFGA. - -You can see the presentations from Jeremy Loy from Headspace and Sarah Funkhouser from OpenLane. - -We are planning next year's content, if you are interested in presenting please add yourselves to he list [here](https://github.com/openfga/community/openfga-in-action.md)! - -## 🌟 Community Spotlight - -[Read.AI](https://read.ai/), one of the earliest OpenFGA adopters, [was recognized by OpenAI for processing 1 trillion tokens](https://www.linkedin.com/posts/readinc_huge-shout-out-to-this-crew-and-all-read-activity-7384229591386783744-noSI). They use OpenAI for RAG use cases powered by OpenFGA :). - -Congrats to [Luke Woloszyn](https://www.linkedin.com/in/lukewoloszyn/), [Andrew Powers](https://www.linkedin.com/in/andrew-powers-geo/), and [Sam Matthews](https://www.linkedin.com/in/mapsam/) for such a great achievement! - -- Hierarchy of Needs? -- AuthZ for MCPs? - -## 📣 Community Updates & Events - -### Recent Talks & Content - -- [Carla Urrea](https://www.linkedin.com/in/carlastabile/) published [a LinkedIn Course about OpenFGA en Español](https://www.linkedin.com/learning/openfga-implementacion-de-fine-grained-authorization/que-es-openfga-y-por-que-usarlo) and a blog post about [Understanding ReBAC and ABAC Through OpenFGA and Cedar](https://auth0.com/blog/rebac-abac-openfga-cedar/). A repository with the examples used in the blog post is [here](https://github.com/openfga/openfga-cedar-comparison). - -- [Deepu K Sasidharan](https://www.linkedin.com/in/deepu05/) presented about [Delay the AI Overlords: How OAuth and OpenFGA Can Keep Your AI Agents from Going Rogue](https://www.youtube.com/watch?v=-V251N-pYYI) at DevOxx. - -- KubeCon links: - -### Upcoming Events - KubeCon Europe - -- [Andres Aguiar](https://www.linkedin.com/in/aaguiar/) from Okta will be presenting at KubeCon Europe, together with [Erica Hughberg](https://www.linkedin.com/in/alicejgibbons/) from Tetrate about [Design Patterns for Consistent Centralized Authorization](https://kccncna2025.sched.com/event/27Fek). Great chance to see [OpenFGA and Envoy](https://www.cncf.io/projects/envoy/) working together! - -- [Andres Aguiar](https://www.linkedin.com/in/tylernix/) from Okta will host the OpenFGA Project Lightning talk [OpenFGA: Google Zanzibar Style Authorization Made Developer-Friendly](https://kccncna2025.sched.com/event/27d4i). - -OpenFGA will also have a kiosk at the KubeCon Project Pavilion during all afternoons. - -## **See you soon!** - -Fine-Grained News is published monthly. If you have any feedback, want to share your OpenFGA story, or have a noteworthy update, please let us know on any of our [community channels](https://openfga.dev/community) or at [community@openfga.dev](mailto:community@openfga.dev). -