> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentwallex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture de securite

> Quatre couches de securite — identite, moteur de politiques, signature MPC et intervention humaine — protegent vos agents.

## Presentation

AgentWallex est construit sur le principe que les agents IA ne devraient **jamais avoir acces aux cles privees**. A la place, les transactions sont signees en utilisant le calcul multi-parties (MPC), ou aucune partie ne detient jamais la cle complete.

La plateforme applique la securite a travers quatre couches independantes. Une transaction doit passer par toutes avant d'etre diffusee sur la blockchain.

## Quatre couches de securite

### Couche 1 : Identite et authentification

Chaque requete API est authentifiee en utilisant un systeme a deux jetons :

* **Cle API** (`awx_...`) — Longue duree, identifie votre compte. Stockez-la en securite dans des variables d'environnement.
* **Jeton de session** — Courte duree, scope a des agents et operations specifiques. Rotation automatique.

```typescript theme={null}
// API key authenticates your account
const aw = new AgentWallex({ apiKey: process.env.AGENTWALLEX_API_KEY! });

// Session tokens are managed internally by the SDK
// Each agent gets its own scoped session
```

**Proprietes cles :**

| Propriete              | Detail                     |
| ---------------------- | -------------------------- |
| Rotation des cles      | Sans temps d'arret         |
| Expiration de session  | Configurable : 1-24 heures |
| Portee des permissions | Par agent                  |
| Liste blanche d'IP     | Plans Growth et Enterprise |

### Couche 2 : Moteur de politiques

Chaque transaction doit passer par le moteur de politiques avant la signature. Les politiques sont evaluees dans l'ordre — la premiere violation arrete la transaction.

Le moteur de politiques prend en charge :

* Limites de depenses (par transaction, quotidiennes, mensuelles)
* Listes blanches et noires d'adresses
* Restrictions de jetons
* Controles de velocite (limitation du debit)
* Regles de planification temporelle
* Acheminement d'approbation humaine

Consultez [Moteur de politiques](/fr/features/policy-engine) pour les details complets de configuration.

### Couche 3 : Signature MPC (Paratro)

AgentWallex utilise le protocole MPC a seuil 2-sur-3 de Paratro :

| Fragment   | Detenteur                        | Objectif                |
| ---------- | -------------------------------- | ----------------------- |
| Fragment 1 | Service de signature AgentWallex | Signature active        |
| Fragment 2 | Noeud de garde independant       | Signature active        |
| Fragment 3 | Stockage a froid                 | Recuperation uniquement |

**Proprietes de securite critiques :**

* La cle privee complete n'est **jamais reconstituee** en memoire
* N'importe quels 2 des 3 fragments peuvent signer une transaction
* La compromission d'un seul fragment ne compromet pas le portefeuille
* La generation de cles utilise la generation distribuee de cles (DKG) — aucune partie ne voit jamais la cle complete

### Couche 4 : Intervention humaine

Pour les transactions de haute valeur ou inhabituelles, AgentWallex peut acheminer vers une approbation humaine :

* Transactions au-dessus d'un seuil configurable
* Transactions vers de nouvelles adresses (jamais vues)
* Schemas inhabituels detectes par la surveillance des anomalies

```json theme={null}
{
  "event": "approval.requested",
  "data": {
    "transactionId": "tx_pending_123",
    "agentId": "agent_abc123",
    "amount": "2500.00",
    "reason": "Amount exceeds humanApprovalThreshold (1000)",
    "expiresAt": "2025-01-15T11:00:00Z"
  }
}
```

Les approbations peuvent etre gerees via le tableau de bord, l'API ou l'integration webhook.

## Architecture de politiques a deux niveaux

AgentWallex applique les politiques a deux niveaux independants :

### Couche metier (configuree par le developpeur)

Vos regles personnalisees — limites de depenses, listes blanches, controles de velocite. Celles-ci sont definies via l'API ou le tableau de bord et peuvent etre mises a jour a tout moment.

### Filet de securite d'infrastructure (applique par Paratro)

Limites strictes appliquees au niveau de la signature MPC qui **ne peuvent pas etre outrepassees** par des appels API :

| Controle                   | Valeur par defaut   | Description                                          |
| -------------------------- | ------------------- | ---------------------------------------------------- |
| Plafond quotidien absolu   | 50 000 \$           | Plafond strict independamment de la politique metier |
| Detection d'anomalies      | Active              | Analyse de patterns basee sur le ML                  |
| Gel d'urgence              | Toujours disponible | Verrouillage instantane du portefeuille              |
| Periode de refroidissement | 10 minutes          | Apres le gel, ne peut pas etre degele immediatement  |

<Warning>
  Meme si votre cle API est compromise, le filet de securite d'infrastructure empeche les pertes catastrophiques. L'attaquant ne peut pas outrepasser les limites appliquees par Paratro.
</Warning>

## Cycle de vie de la gestion des cles

### Generation des cles

Les cles sont generees en utilisant la generation distribuee de cles (DKG). A aucun moment, aucune partie ne voit la cle privee complete :

1. Chacun des 3 noeuds MPC genere un fragment aleatoire.
2. Les fragments sont combines cryptographiquement pour produire une cle publique.
3. La cle privee correspondante n'existe que sous forme de fragments distribues.

### Rotation des cles

Les fragments de cles sont soumis a une rotation periodique sans changer l'adresse du portefeuille. C'est ce qu'on appelle le « partage proactif de secret » — les anciens fragments deviennent inutiles apres la rotation.

### Gel d'urgence

Toute partie autorisee peut geler instantanement un portefeuille :

<CodeGroup>
  ```typescript SDK theme={null}
  await aw.agents.freeze("agent_abc123");
  ```

  ```bash API theme={null}
  curl -X PUT https://api.agentwallex.com/api/v1/agents/agent_abc123/status \
    -H "X-API-Key: awx_your_api_key" \
    -H "Content-Type: application/json" \
    -d '{"status": "inactive"}'
  ```
</CodeGroup>

Les portefeuilles geles ne peuvent signer aucune transaction tant qu'ils ne sont pas explicitement degeles (avec une periode de refroidissement obligatoire).

## Journalisation d'audit

Chaque action est journalisee de maniere immuable :

* Toutes les requetes API (avec IP, user agent, horodatage)
* Toutes les evaluations de politiques (reussite/echec avec motif)
* Toutes les operations de signature
* Tous les evenements de gel/degel
* Toutes les livraisons de webhooks

| Plan       | Retention des journaux |
| ---------- | ---------------------- |
| Starter    | 90 jours               |
| Growth     | 1 an                   |
| Enterprise | Personnalise           |

Interrogez les journaux d'audit via l'API :

```bash theme={null}
curl -X GET "https://api.agentwallex.com/api/v1/audit-logs?page_num=1&page_size=20" \
  -H "X-API-Key: awx_your_api_key"
```