AL1 Supervision par conception
Des plans structurés, des appels d'outils traçables et des points de transfert clairs où une personne décide.
Méthodes de sécurité pour les systèmes agentiques
Recherche sur la supervision, les limites de capacité, l'utilisation sécurisée des outils et le comportement de refus robuste.
Un système qui reste utile pour les bonnes requêtes et fiable face aux mauvaises.
supervision limites refus
Notre vision de la sécurité
La sécurité est une propriété architecturale, non un prompt de dernière couche
Notre travail de sécurité est intégré à l'architecture : des limites de capacité imposées à l'exécution, des surfaces de supervision qui gardent les relecteurs humains rapides et informés, et un comportement de refus évalué face à la pression adverse. L'objectif est un système qui reste utile pour les bonnes requêtes et fiable face aux mauvaises.
sécurité au niveau du prompt → tient jusqu'au prochain contournement
au niveau de l'architecture → la limite tient même quand le prompt cède
Trois engagements
Où se situe le travail de sécurité
AL2 Limites de capacité
Les agents opèrent à l'intérieur de listes d'autorisation explicites pour les outils et les données. Les limites sont imposées au niveau de l'exécution, et non seulement par le prompt.
AL3 Refus robuste
Le comportement de refus est testé face aux prompts adverses, à l'injection de prompt et à la pression incitative. L'exigence est « reste utile pour les bonnes », et non « refuse les mauvaises ».
Liste d'autorisation · politique d'exécution
Les outils sont refusés par défaut. Les autorisations sont explicites.
C'est l'exécution qui décide, pas le prompt. Un outil absent de la liste d'autorisation ne peut être invoqué, même si l'agent estime qu'il le devrait.
outil portée région verdict
read_doc allow public + signed pass
web_search allow rate-limited pass
send_email deny requires reviewer block
shell_exec deny no sandbox match block
pay_invoice deny human-only block
compile_code allow sandbox · read pass
Robustesse du refus
Reste utile pour les bonnes requêtes. Reste ferme sous pression.
L'exigence n'est pas « refuse les mauvaises ». L'exigence est « reste utile pour les bonnes », mesurée face aux formulations maladroites et à la pression adverse sur une même évaluation.
good ask, plain 0.96
good ask, awkward 0.91
bad ask, plain 0.98
bad ask, jailbreak 0.94
bad ask, prompt inj. 0.92
bad ask, role-play 0.95
reste utile refuse correctement
Transfert à la supervision
Cinq étapes, deux points de contact humains.
Les relecteurs voient le plan avant l'exécution et une trace de vérification ponctuelle après. L'agent n'exécute jamais rien que le relecteur n'ait approuvé au niveau du plan.
01
agent
plan
structured plan emitted
02
human
reviewer
approve · revise · deny
03
agent
execute
allow-listed tools only
04
human
reviewer
spot-check trace
05
agent
report
full audit trail · signed
Surface de publication
Public là où c'est utile. Privé là où cela nous différencie.
01 capability-boundary API public with reference runtime
02 audit-stream spec public JSONL · OTel-compatible
03 refusal evaluation harness public paper + scoring code
04 adversarial prompt corpus partial subset under research use
05 internal red-team playbook private differentiating
Ce que nous avons publié
Des méthodes pour les agents à capacité limitée, des spécifications de flux d'audit et des évaluations de refus. Là où le travail nous différencie, nous gardons le mécanisme sous-jacent privé ; là où ce n'est pas le cas, nous le contribuons en amont.