AgentRail équipe des agents IA avec une identité déléguée et un budget plafonné. L’agent choisit ensuite seul sa stratégie, ses marchands et son flow, avec approbations si nécessaire et audit complet.
L’agent obtient juste le minimum nécessaire, puis AgentRail peut suspendre, expirer ou révoquer.
Aujourd’hui, un agent sait lire, cliquer et remplir des formulaires. Mais il bloque dès qu’il faut une identité, un email, un navigateur persistant, une carte virtuelle, une permission de dépenser ou une preuve d’audit.
Les agents n’ont pas de boîte mail, pas de profil navigateur, pas de contexte durable pour agir comme des opérateurs stables.
Ils peuvent proposer des achats, mais pas exécuter avec un vrai cadre de dépense, de plafonds et de validation.
Quand un agent agit, il faut savoir qui a demandé, quoi, où, pour combien, avec quel résultat.
Secrets partagés, cartes humaines utilisées à la main, validations Slack, logs incomplets. Rien de tout ça ne scale proprement.
AgentRail n’est pas un produit pour “faire comme un humain”. C’est une couche de gouvernance qui permet à un agent d’agir au nom d’un owner réel, dans des limites explicites.
Une seule couche pour exécuter, payer, contrôler et justifier.
Alias email par agent, navigateur dédié, mots de passe gérés, sessions persistantes, coffre-fort de secrets.
Carte virtuelle ou wallet par agent, plafonds par tâche, par jour, par agent, par marchand.
Default deny, validation au-dessus d’un seuil, plafonds par agent et révocation immédiate.
Screenshots, logs, facture, justification, prompt d’origine, résultat final. Tout est traçable.
Le produit minimal qui crée de la valeur sans décider à la place de l’agent.
Le produit délivre des capacités. L’agent, lui, garde son autonomie complète sur la stratégie, le marchand et le flow d’exécution.
Identity ou payment, au moment exact où il en a besoin, sans flow imposé par la plateforme.
Budget, durée, approval éventuelle, provider backing, références d’audit et possibilité de révocation.
Il choisit son marchand, son checkout, son fallback. AgentRail ne fournit que les moyens d’agir.
Audit trail, seuils d’approbation, expiration naturelle et kill switch immédiat.
Le point d’entrée le plus crédible : permettre à un agent d’obtenir un budget temporaire et une identité déléguée pour souscrire à un service web, avec validation si nécessaire.
L’agent demande une inbox déléguée, récupère les emails utiles, puis continue seul son flow.
Notion, OpenAI, Vercel, AWS, Linear, Calendly. L’agent choisit le marchand, AgentRail ne fournit que le rail de paiement.
Le bot peut redemander un budget borné pour un renouvellement récurrent, avec usage retracé.
Au-delà d’un seuil, l’owner doit valider avant qu’une capability ne soit délivrée.
Les équipes qui ont déjà des agents, mais pas encore une façon propre de leur laisser agir.
Pour passer du prototype au monde réel sans bricoler identité, carte, approvals et logs.
Pour laisser des agents dépenser dans un cadre explicite, sans perdre le contrôle financier et légal.
Pour déployer chez leurs clients des agents réellement opérables, pas seulement démonstratifs.
On cherche 5 équipes design partners pour cadrer le MVP, valider les cas d’usage et construire la première version avec elles.