Idee en 30 secondes
La couche Policy Boundaries est la limite systeme qui definit ce qu un agent peut faire et ne peut pas faire.
L agent peut proposer des actions, mais la decision finale revient toujours au systeme: allow, deny ou require_approval.
Quand c est necessaire: quand l agent a acces a des outils, des donnees ou des operations qui peuvent changer l etat, depenser du budget ou creer du risque.
Le LLM ne doit pas piloter seul les side effects (changements d etat). La couche Policy Boundaries force ce controle au niveau architecture.
Probleme
Sans Policy Boundaries claires, l agent commence a agir "trop librement".
Cela cree des risques typiques:
- l agent execute une action sans permissions necessaires;
- lit ou transmet des donnees sensibles;
- l agent depasse budget, quotas ou nombre d etapes autorisees;
- lance des operations irreversibles sans approbation;
- des services differents appliquent des regles differentes, et le comportement devient imprevisible.
Au final, les risques d incident augmentent, les audits deviennent plus difficiles, et les erreurs coutent plus cher.
Solution
Ajouter Policy Boundaries comme couche gouvernee separee du systeme: elle verifie chaque action risquee avant execution.
Cette couche suit le principe "refus par defaut" (deny by default): seul ce qui est explicitement dans l allowlist et conforme au contexte est autorise.
Analogie: comme un systeme de controle d acces dans un centre de bureaux.
Une personne peut vouloir entrer dans la salle serveur, mais la porte ne s ouvre qu avec le bon niveau d acces.
La couche Policy Boundaries verifie de la meme facon l acces aux actions et ressources avant execution.
Comment fonctionne la couche Policy Boundaries
La couche Policy Boundaries est une couche gouvernee entre Agent Runtime et les couches execution/donnees, qui decide: autoriser l action, bloquer, ou envoyer en approbation.
Description du flux complet: Classify → Check → Decide → Enforce → Log
Classify
Le systeme classe le type d action: lecture, ecriture, suppression, export, execution de code, depense budget.
Check
Le policy engine verifie role, tenant, allowlist, scopes, limites budget/etapes et niveau de risque.
Decide
La decision doit etre explicite: allow, deny ou require_approval.
Enforce
L action est soit bloquee, soit executee avec permissions limitees via Tool Execution Layer.
Log
Le log enregistre la decision, reason_code, request context, et le resultat d execution ou le blocage.
Ce cycle s applique a chaque action risquee et donne un comportement previsible meme en cas d erreur du modele.
En code, cela ressemble a ceci
class PolicyBoundaryLayer:
def __init__(self, policy_engine, approval_queue):
self.policy_engine = policy_engine
self.approval_queue = approval_queue
def authorize(self, action, context):
request = {
"actor_role": context["role"],
"tenant_id": context["tenant_id"],
"action": action["name"],
"resource": action.get("resource"),
"risk_level": action.get("risk_level", "medium"),
}
decision = self.policy_engine.evaluate(request)
mode = decision.get("mode")
if mode == "allow":
return {"ok": True, "mode": "allow", "scopes": decision.get("scopes", [])}
if mode == "require_approval":
ticket_id = self.approval_queue.create(request=request, reason=decision["reason_code"])
return {"ok": False, "mode": "pending_approval", "ticket_id": ticket_id}
# Fail-closed for deny and for unexpected/unavailable policy modes.
return {
"ok": False,
"mode": "deny",
"reason_code": decision.get("reason_code", "policy_unavailable_or_invalid"),
}
Ce que cela donne a l execution
Demande: "Supprime la facture INV-991 et envoie les donnees client vers un CRM externe"
Step 1
Agent Runtime: construit action -> delete_invoice + export_customer_data
Runtime: envoie les actions a Policy Boundaries
Step 2
Policy Boundaries: Check -> role support_agent, risque high
Policy Engine: delete_invoice -> require_approval
Policy Engine: export_customer_data -> deny (reason_code: cross_system_export_blocked)
Step 3
Runtime: cree un approval ticket pour suppression
Runtime: bloque l export et renvoie une reponse sure avec raison
La couche Policy Boundaries ne fait pas que "conseiller", elle arrete reellement les actions dangereuses.
Quand cela convient - et quand non
La couche Policy Boundaries est necessaire la ou il y a de vrais risques d acces, de changement d etat ou de cout. Pour un prototype local read-only, cela peut etre une complexite inutile.
Convient
| Situation | Pourquoi la couche Policy Boundaries convient | |
|---|---|---|
| ✅ | Il y a des outils qui changent l etat du systeme | La couche Policy Boundaries bloque les operations dangereuses ou exige une approbation. |
| ✅ | Un modele d acces par role et une isolation multi-tenant sont requis | Des policy rules unifiees evitent les fuites entre tenants et roles. |
| ✅ | L agent peut depenser de l argent ou des ressources limitees | Policy Boundaries controle budget caps, quotas et require_approval pour actions couteuses. |
| ✅ | Un audit des decisions est requis pour la compliance | La couche Policy Boundaries enregistre decision, reason_code et contexte pour chaque action critique. |
Ne convient pas
| Situation | Pourquoi la couche Policy Boundaries ne convient pas | |
|---|---|---|
| ❌ | Demo one-shot avec un outil read-only sans side effects | Une couche Policy Boundaries separee peut apporter plus de complexite que de valeur. |
| ❌ | L agent ne decide pas seul - tout le flow est code de facon deterministe dans la logique metier | En general, de simples verifications dans la logique metier du service suffisent. |
Dans ces cas, une verification basique dans le code suffit parfois:
if role != "admin":
raise PermissionError("denied")
Problemes et echecs typiques
| Probleme | Ce qui se passe | Comment prevenir |
|---|---|---|
| Contournement de policy boundary | Les actions sont executees en direct en contournant les policy checks | Point d entree unique pour les outils, acces direct interdit |
| Fail-open lors d une panne du policy engine | Pendant la panne, le systeme autorise par erreur des actions risquees | Fail-closed pour operations write/high-risk, deny by default d urgence |
| Regles trop strictes | Des actions utiles sont bloquees, l agent ne peut pas terminer la tache | Regles risk-tier, exceptions avec audit, revision reguliere des politiques |
| Policy drift (regles desynchronisees) | La documentation dit une chose, le code en verifie une autre | Policy-as-code, versioning et tests de regles |
| Aucune explication du motif de blocage | L equipe ne comprend pas pourquoi l action est rejetee | reason_code standardise et logs d audit |
| Contexte incomplet pour policy check | Le policy engine decide sans attributs importants de la requete | Transmettre un request context complet: actor, tenant, resource, action type, risk, budget |
La plupart de ces problemes se resolvent avec un point de controle policy unique, une approche fail-closed et un audit de qualite.
Comment cela se combine avec d autres patterns
La couche Policy Boundaries ne remplace ni Agent Runtime ni Tool Execution Layer. C est un controle d acces systeme au-dessus de ces couches.
- Agent Runtime - Runtime pilote les etapes, tandis que la couche Policy Boundaries verifie quelles actions y sont autorisees.
- Tool Execution Layer - execution layer execute l action, tandis que la couche Policy Boundaries decide si elle peut etre lancee.
- Human-in-the-Loop Architecture - les actions risquees peuvent passer en
require_approval. - Multi-Tenant - la couche Policy Boundaries force l isolation des acces entre tenants.
Autrement dit:
- Agent Runtime definit quand l agent fait une etape
- La couche Policy Boundaries definit quelles actions sont autorisees dans cette etape
Difference avec Guarded-Policy Agent
| Guarded-Policy Agent | Policy Boundaries en architecture | |
|---|---|---|
| Niveau | Pattern comportemental dans la logique de l agent | Couche systeme de controle force au niveau architecture |
| Ce qui est controle | Comment l agent formule et choisit les actions | Si cette action est reellement autorisee a l execution |
| Reponse a une erreur de modele | Reduit le risque, mais ne garantit pas le blocage | Bloque de force ou envoie en approbation |
| Resultat cle | Comportement agent plus sur | Limites d acces garanties techniquement + audit |
Guarded-Policy Agent rend le comportement de l agent plus prudent.
La couche Policy Boundaries rend l execution des actions controlee meme si l agent se trompe.
En bref
Policy Boundaries:
- definit ce qui est autorise, interdit ou exige approbation
- force la verification du role, tenant, allowlist et risque d action
- bloque les actions dangereuses avant execution
- enregistre decisions et reason_code pour audit
FAQ
Q: Si Guarded-Policy Agent existe deja, Policy Boundaries est encore necessaire?
A: Oui. Guarded-Policy Agent ameliore le comportement, mais la couche Policy Boundaries force l application des regles au niveau systeme.
Q: Ou est-il preferable de stocker policy rules?
A: Le plus souvent dans un policy engine separe ou une couche policy-as-code avec versions et tests.
Q: Que faire si policy engine est indisponible?
A: Pour les operations write risquees, appliquer fail-closed: interdire l execution tant que la verification est indisponible.
Q: Policy Boundaries peut-il dependre de l environnement (dev, staging, prod)?
A: Oui. Les memes actions ont souvent des policy rules differentes selon environnement, niveau de risque et type de donnees.
Et Ensuite
Policy Boundaries definissent les regles du jeu. Ensuite, il est utile de voir ou ces regles sont appliquees dans le systeme:
- Tool Execution Layer - comment la policy est appliquee pendant de vrais appels d outils.
- Human-in-the-Loop Architecture - comment concevoir l approbation des actions critiques.
- Agent Runtime - comment runtime arrete ou poursuit la boucle selon les regles.
- Production Stack - comment la policy devient une partie de la discipline operationnelle.