Pattern Guarded-Policy Agent : actions sures par regles

Essence Du Pattern

Guarded-Policy Agent est un pattern ou, avant chaque action, on applique un policy-gate : allow, deny, rewrite ou escalate selon des regles formalisees.

Quand l'utiliser : quand les actions de l'agent doivent passer des verifications formelles de regles avant execution.

L'idee est simple : l'agent peut proposer n'importe quoi, mais seuls les pas qui passent les checks de policy sont executes.

Guardrails de policy verifient en general :

• tools et parametres autorises
• limites d'acces aux donnees
• limites budget/time
• niveau de risque de l'action

Probleme

Imagine un scenario bancaire : il faut transferer 100$, mais on saisit par erreur 10,000$.

Si un systeme sans verifications dit juste "executer", l'action part en prod.

Meme quand :

• le client n'a pas ce solde
• le montant depasse la limite du role
• le compte destinataire est externe et demande des checks supplementaires

Sans policy gate technique, l'agent peut executer une action dangereuse meme quand elle ne devrait clairement pas passer.

C'est le probleme : sans contraintes, n'importe quelle action peut etre executee, meme si elle est :

• dangereuse
• trop couteuse
• en violation des regles d'acces

Solution

Guarded-Policy Agent introduit des verifications obligatoires avant chaque action.

Analogie : c'est comme un tourniquet avec controle d'acces. Meme si une personne veut passer, permissions et regles sont verifiees d'abord. Sans approbation, le systeme ne laisse pas l'action continuer.

Principe cle : le modele peut proposer n'importe quel pas, mais seuls les pas qui passent le policy gate sont executes.

Chaque action passe par :

1. verification des permissions
2. verification budget/limites
3. verification d'acces aux donnees
4. evaluation du risque

Ensuite, policy-engine retourne une decision :

• autoriser (allow) - executer
• reecrire (rewrite) - remplacer par une variante sure
• bloquer (deny) - bloquer
• escalader (escalate) - transferer a un humain

Cela protege contre les cas ou l'agent peut :

• ecrire au lieu de lire
• exfiltrer des donnees sensibles
• lancer une requete couteuse
• faire une operation destructive

Fonctionne bien si :

• l'agent n'a pas d'acces direct aux tools
• l'execution passe uniquement par policy-engine
• chaque action doit passer allow/deny/rewrite/escalate

La fiabilite d'un agent n'est pas seulement "bonne intention", mais des actions qu'il ne peut techniquement pas executer hors des regles.

Comment Ca Fonctionne

Policy-gate n'execute pas l'action lui-meme. Il decide si elle peut etre executee et sous quelle forme.

En Code, Ca Donne Ca

action = agent.next_action(context)

decision = policy_engine.evaluate(
    action=action,
    user_role=user_role,
    budget_state=budget_state,
)

if decision.type == "allow":
    result = execute(action)
elif decision.type == "rewrite":
    context.append(decision.reason)
    return agent.next_action(context)  # reproposer via le meme gate
elif decision.type == "escalate":
    result = human_approval(action)
else:
    result = stop_with_reason(decision.reason)

return result

Principe cle : agent intent et execution sont deux couches differentes. Policy se place entre intent et execution (execution).

Le modele n'a pas d'acces direct a l'execution, seulement via une couche d'execution policy-gated (execution layer).

A L'execution, Ca Ressemble A Ca

Goal: "Exporte tous les clients en CSV et envoie vers un email externe"

Agent action:
- tool: export_customers
- params: include_pii=true
- destination: external_email

Policy check:
- rule: PII export to external channels = deny
- decision: bloquer (block)
- reason: policy.pii_exfiltration_guard

Result:
- l'action n'a pas ete executee
- un refus controle a ete renvoye

Quand Ca Convient - Et Quand Non

Adapte

Non Adapte

Parce que la couche policy ajoute de la complexite d'ingenierie : regles, tests de regles et mises a jour continues pour les processus metier.

Difference Avec Supervisor Agent

Guarded-Policy est une barriere technique "par regles".

Supervisor Agent est un controle de supervision "selon la situation".

Quand Utiliser Guarded-Policy (vs Autres Patterns)

Utilisez Guarded-Policy quand il faut stopper des actions risquees avant execution selon des regles de policy explicites.

Test rapide :

• si vous avez besoin de "check allow/deny avant action" -> Guarded-Policy
• si vous avez besoin de "recuperer apres erreur deja arrivee" -> Fallback-Recovery Agent

Comment Combiner Avec D'autres Patterns

• Guarded-Policy + ReAct : chaque action de la boucle passe d'abord par policy-check, puis est executee.
• Guarded-Policy + Supervisor : Supervisor decide quand escalader, et policy-engine applique automatiquement les regles strictes.
• Guarded-Policy + Fallback-Recovery : si une action est bloquee ou si une etape echoue, l'agent bascule vers un fallback autorise et sur.

En Bref

Avantages Et Inconvenients

FAQ

Q: Peut-on remplacer les checks policy uniquement par des instructions de prompt ?
A: Non. Prompt opere au niveau intent, mais ne controle pas l'execution. Policy doit etre appliquee dans la couche runtime.

Q: Qu'est-ce qui est mieux : allowlist ou blocklist ?
A: Pour les systemes a haut risque, il est plus sur de commencer par allowlist : seules les actions explicitement definies sont autorisees.

Q: Que faire si une regle est trop stricte et bloque une action utile ?
A: Ajouter des exceptions controlees : scope, conditions de role, ou chemin avec approbation humaine au lieu d'un deny total.

Et Ensuite

L'approche Guarded-Policy protege l'agent contre les actions dangereuses avant execution.

Mais que faire quand l'agent a besoin d'execution de code sure dans un environnement isole ?