Axiomatics : décider ce qu’une identité peut réellement faire

Le modèle d’autorisation part d’une requête qui porte sur plusieurs dimensions.^[1]

SubjectQui agit ?

• Utilisateur
• Agent
• Service
• Application
• Compte technique

ActionQue veut-il faire ?

• Read
• Export
• Approve
• Delete
• Execute
• Call tool

ResourceSur quoi ?

• API
• Document
• Record
• Dataset
• Tool
• Service

ContextDans quelles conditions ?

• Environment
• Time
• Device
• Risk
• Location
• Data sensitivity
• Relationship

Une politique peut combiner plusieurs de ces dimensions pour produire une décision adaptée à l’exécution en cours. Aucune décision ne les utilise toutes par obligation.

Axiomatics supporte ces modèles dans ses politiques.^[1] L’intérêt n’est pas de supprimer les rôles, mais d’éviter de transformer chaque combinaison de contexte en nouveau rôle statique.

Le Policy Decision Point reçoit une demande d’autorisation, évalue les politiques et retourne une décision : Permit ou Deny dans le cas le plus simple. Il peut aussi retourner des obligations ou de l’advice, que le composant d’enforcement applique avec la décision.^[1]

Le Policy Enforcement Point se trouve sur le chemin de l’action. Il intercepte la requête, construit la demande d’autorisation, appelle le PDP, reçoit le résultat et applique la décision avant l’accès à la ressource.

Une décision ABAC nécessite des attributs. Axiomatics peut les récupérer auprès de sources externes via des Policy Information Points, plutôt que d’imposer la réplication de toutes les identités dans la plateforme. Sources et interfaces citées dans la documentation :^[1]

• Active Directory
• LDAP
• Microsoft Entra ID
• Workday
• ServiceNow
• SAP S/4HANA
• Power BI
• Jira
• Google Workspace
• GCP
• SQL / JDBC
• Graph
• REST / HTTP
• SCIM
• IdP / JWT

Cette liste reprend les sources citées ; elle ne qualifie pas chacune comme connecteur natif certifié.

Le Policy Administration Point et les composants de management servent à définir, tester, publier et faire évoluer les politiques.^[1]

• Policy authoring
• Attribute management
• Policy testing
• Policy publishing
• Policy lifecycle
• Configuration management
• Policy analysis (selon version)
• Collaboration (selon version)

Une politique peut aussi devenir du code

Deux approches coexistent : interface graphique et policy-as-code. Le langage mis en avant est ALFA (Abbreviated Language for Authorization), avec XACML comme fondation de politique.^[1]

policy customerExport {
    permit if
        subject.type == "ai-agent"
        and action == "export"
        and resource.type == "customer-record"
        and environment.destination == "reporting-platform";
}

Tester la politique avant son déploiement

La documentation associe le Policy Testing Framework et les pratiques Policy DevOps aux tests de politiques, au policy tracing, à la CI/CD, à la validation avant production et au déploiement.^[1]

Sources : documentation Axiomatics.^[1] CAQ ne fait pas d’Axiomatics une IGA complète.

A · Runtime decision

API, microservices, applications contrôlables, couches de données ; MCP ou A2A lorsque le point d’enforcement existe.

B · Policy-derived provisioning

Axiomatics calcule les permissions ; l’orchestrateur ou le système d’identité exécute le provisioning.

C · Token enrichment

Les claims du token sont calculés à partir des politiques au moment de l’émission.

Ces trois modes, décrits dans la documentation,^[1] répondent à des besoins différents et ne sont pas requis simultanément.

• REST synchrone
• JSON / XML
• API runtime
• API d’administration
• OpenAPI / Swagger
• SDK Java officiel
• Correlation ID
• Obligations / advice
• Stateless runtime

Des guides d’intégration sont cités pour plusieurs API gateways, notamment Kong, Apigee, MuleSoft, Axway, Tyk, Istio et Envoy.^[1]

Ce que la plateforme ne fournit pas elle-même

La documentation 2026 indique l’absence native de :^[1]

• API key management
• Rate limiting
• WebSocket / SSE streaming API
• Webhook / message broker async
• Global SaaS status page
• Dashboard API complet

Rate limiting et restrictions réseau relèvent de l’architecture environnante, par exemple un load balancer ou une gateway contrôlés par le client. C’est une frontière fonctionnelle.

Dans la documentation 2026, Axiomatics est décrit comme self-hosted : on-premises, Docker, Kubernetes, cloud contrôlé par le client ou architecture hybride. Les moteurs de décision sont stateless, scalables verticalement et horizontalement derrière un load balancer, compatibles avec l’autoscaling Kubernetes.^[1]

Load balancing, géoréplication, failover, reprise d’activité et objectifs RTO/RPO dépendent de l’architecture exploitée par le client. Aucun SLA n’est indiqué ici.

Les moteurs produisent des logs d’autorisation qui retracent les décisions évaluées. Un correlation ID fourni dans la requête peut apparaître dans les logs pour rapprocher une décision d’une transaction applicative. La documentation mentionne aussi l’export et la configuration des logs, leur exploitation via les outils du client, l’intégration SIEM ou BI et l’audit administratif des modifications.^[1] Dans le modèle self-hosted, stockage et rétention restent sous contrôle du client.

Le moteur ne dépend pas du caractère humain de l’identité : un agent, un service, une application ou un robot peut être le sujet d’une politique si les attributs nécessaires sont disponibles.^[2] Dimensions possibles d’une décision pour un agent :

• Agent identity
• Human requester
• Tool
• Action
• Resource
• Data sensitivity
• Destination
• Environment
• Relationship

Autoriser les tool calls au moment de l’action

Dans une architecture MCP, un point d’enforcement peut demander une décision avant qu’un tool call n’atteigne le serveur ou la ressource protégée. Le PDP peut prendre en compte l’identité, l’outil, les paramètres, la ressource et le contexte.^[3] Voir sécuriser MCP.

Appliquer les politiques aux données utilisées par l’agent

Selon l’architecture, l’autorisation peut limiter les documents, enregistrements, datasets, champs, catégories de données ou résultats retournés à l’agent.^[2] Axiomatics ne fournit pas de moteur RAG : il décide lorsque le point d’enforcement et les attributs sont disponibles. Voir protéger RAG et mémoire.

Décider aussi lorsqu’un agent agit avec un autre agent

La vision d’autorisation pour l’IA d’Axiomatics inclut A2A et l’IA agentique.^[2] Le principe reste le même : un sujet demande une action sur une ressource dans un contexte, et une politique décide.

Produit décrit dans la documentation 2026

Pas d’IA intégrée au produit principal, pas de traitement IA général en production, pas de réutilisation des données client pour entraîner des modèles.

Policy Companion · pilote

Décrit comme un pilote séparé du produit principal.

Roadmap

Assistance au policy authoring, génération depuis le langage naturel, analyse, recommandations. Non disponible en production à la date de la documentation.

Source : documentation Axiomatics.^[1]

Axiomatics AB est certifiée ISO/IEC 27001:2022 (certificat 27001-1085, expiration indiquée au 6 septembre 2027). Le périmètre couvre le développement, le support, la vente et la maintenance de la plateforme d’autorisation dynamique externalisée.^[4]

La documentation sécurité décrit aussi des revues de code, l’usage de SonarQube et Snyk, OWASP SAMM, des SBOM, la gestion des secrets dans les pipelines, des tests de sécurité et des pentests.^[1]

Un modèle où le client contrôle l’instance

Dans l’architecture self-hosted décrite, les données de production restent dans l’environnement du client. Politiques, configurations et logs existent dans l’instance ; Axiomatics n’est pas décrit comme hébergeant un référentiel SaaS de données de production client.^[1]