OPA (Open Policy Agent) : gouverner ses agents IA et son infrastructure avec des politiques déclaratives
À mesure que les agents IA gagnent en autonomie et touchent à des outils sensibles, bases de données, APIs internes, fichiers, opérations sur l’infrastructure, la question de ce qu’ils ont le droit de faire devient aussi importante que celle de ce qu’ils savent faire. Coder ces règles à l’intérieur de chaque agent revient à disperser la sécurité dans un dédale de scripts difficile à auditer. OPA (Open Policy Agent), projet sous licence Apache 2.0, propose une réponse éprouvée : externaliser la décision d’autorisation dans un moteur de politique unique, interrogé en quelques millisecondes par tout composant qui en a besoin.
Un moteur de politique unifié pour des décisions distribuées
OPA fonctionne comme un service compagnon : il charge un ensemble de politiques écrites en Rego, son langage déclaratif, et expose une API JSON. Un service métier, un proxy, un orchestrateur d’agents ou un cluster Kubernetes envoie une requête de décision accompagnée de son contexte, et OPA répond autorisé ou refusé, avec d’éventuelles justifications. La politique vit en dehors du code applicatif, dans son propre dépôt, avec ses propres revues et ses propres tests.
Cette séparation libère deux choses importantes : la possibilité de modifier les règles sans redéployer les applications, et la possibilité d’auditer un comportement en lisant un fichier de politique plutôt que tout le code source d’une stack.
Rego, un langage adapté aux décisions structurées
Rego est un langage déclaratif inspiré de Datalog, conçu pour exprimer « ce qui est vrai » plutôt que « ce qu’il faut faire ». Une règle s’écrit comme une assertion logique sur le contexte de la requête. Une politique qui interdit à un agent IA d’écrire dans certaines tables d’une base peut tenir en quelques lignes :
package agent.db
default allow := false
allow if {
input.action == "read"
not data.tables.sensitive[input.table]
}
allow if {
input.action == "write"
input.user.role == "data_engineer"
input.table in data.tables.writable
}
L’apprentissage demande un effort comparable à celui de Terraform : la syntaxe surprend quelques jours puis devient un outil très productif pour exprimer des conditions complexes sans empiler les if.
Pourquoi c’est pertinent au moment des agents IA
Trois propriétés rendent OPA particulièrement adapté à l’écosystème des agents IA :
- Externalité : les agents construits avec LangGraph, CrewAI, Agno ou Pydantic AI appellent OPA avant chaque exécution d’outil, sans embarquer la logique d’autorisation dans le prompt ou dans leur code.
- Uniformité : la même politique gouverne l’agent IA, le service applicatif qui l’expose et le cluster Kubernetes qui l’héberge. Une équipe sécurité écrit une règle unique sur les données qu’on a le droit de toucher, et la voit appliquée partout.
- Auditabilité : OPA produit en sortie une trace de chaque décision avec les inputs, le verdict et les règles déclenchées. Pour un agent qui prend cinquante décisions par minute, cette traçabilité est ce qui rend la conformité possible.
En pratique, on appelle OPA depuis l’agent au moment où il s’apprête à invoquer un outil : « puis-je exécuter cette requête SQL ? », « puis-je écrire dans ce fichier ? », « puis-je appeler cette API ? ». La réponse arrive en quelques millisecondes, la décision est journalisée, et l’agent poursuit ou refuse.
Trois points d’intégration concrets
- Devant les outils MCP : un wrapper léger interroge OPA avant d’exécuter chaque tool exposé par un serveur MCP. Les politiques peuvent dépendre de l’utilisateur, de l’heure, du contenu de la requête ou du contexte conversationnel.
- Au niveau du reverse proxy : Traefik et Nginx appellent OPA via leur module d’authentification externe pour autoriser ou refuser un appel API avant même qu’il n’atteigne le service backend. Utile pour exposer des agents derrière une passerelle commune.
- Dans Kubernetes : OPA Gatekeeper applique des politiques d’admission sur les manifestes déployés. Un agent qui tenterait de créer un Pod avec des privilèges excessifs serait refusé à la source.
OPA et le control plane d’une stack IA souveraine
Dans une architecture où Keycloak gère les identités, où Langfuse trace les appels LLM, où LiteLLM répartit les requêtes, OPA prend naturellement la place du décideur central des autorisations. L’agent IA devient un consommateur du couple identité plus politique, exactement comme un service métier classique. Le control plane se compose alors d’une triade lisible : qui appelle (Keycloak), a-t-il le droit (OPA), qu’a-t-il fait (Langfuse plus Loki).
Cette séparation suit la même logique que pour les microservices, étendue aux agents : on ne fait pas confiance aveuglément à un agent parce qu’il est intelligent, on l’encadre par des règles vérifiables.
Limites et points d’attention
OPA n’est pas un système de gestion d’identités : il consomme des informations sur l’utilisateur et son contexte, mais c’est à Keycloak, Authentik ou un IdP équivalent de les fournir. Rego se prête mal à l’expression de règles qui demandent un calcul lourd ou une lookup dans une base externe à chaque requête. Pour ces cas, on précharge les données dans OPA via les bundles, qui synchronisent un instantané de données décisionnelles toutes les N secondes.
La courbe d’apprentissage de Rego est réelle. Pour les équipes qui souhaitent commencer plus doucement, Cedar (langage de politiques d’AWS, ouvert) ou Casbin offrent des alternatives moins puissantes mais plus rapides à prendre en main. OPA reste toutefois le standard de fait dans l’écosystème CNCF, ce qui pèse lourd sur la durée.
Ce qu’apporte OPA dans une stack agentique
Externaliser les autorisations dans OPA, c’est traiter la sécurité des agents IA comme on traite la sécurité des microservices : avec une couche dédiée, un langage adapté, des tests, des revues et une traçabilité. À mesure que les agents quittent le prototype pour rejoindre la production, cette couche cesse d’être un confort et devient une exigence. La bonne nouvelle, c’est que les briques existent déjà, qu’elles sont open source, et qu’elles s’intègrent naturellement aux frameworks d’agents couverts dans les derniers articles.
Le projet est disponible sur github.com/open-policy-agent/opa, avec une documentation complète et un playground interactif sur openpolicyagent.org.
