Lesson 2.7 said that the Function App func-lieferanten in Azure demands the system key mcp_extension, and lesson 4.1 introduced a run token that the controller signs with a key from the Key Vault. Both are secrets in the operation of the team. The lesson asks: Where are they, who reads them, how do they change, and what breaks in the process?
Prior knowledge. Secrets, keys and TLS objects, roles at the vault, soft delete and purge protection: "K3, lesson 3.3.2". Never output them: "K3, lesson 3.3.3". Signing in the vault, rotation policies, order after a leak: "K3, lesson 3.3.7". Keyless in Foundry: "AI-103, lesson 1.4". The run token and the gateway: lesson 4.1.
New in this lesson. Each environment (M-09) has one vault in rg-ai500-<environment>. It holds the secret lieferanten-mcp-key (the value of the system key mcp_extension) and the key lauf-signatur (RSA, 2048 bit; assumption). The signing key is planned to change every 90 days (assumption).
The requirement
All numbers are assumptions of the task.
| No. | Requirement | Type | Measure | Weight | Source |
|---|---|---|---|---|---|
| 4.2-01 | No secret in code, configuration, prompt or trace. | R | 0 hits | Must | R-07 |
| 4.2-02 | The key of the Function App is only in the vault and in the gateway. | R | 2 places | Must | 2.7 |
| 4.2-03 | The private part of the signing key never leaves the vault. | R | 0 exports | Must | 4.1-03 |
| 4.2-04 | A planned change does not discard any valid run token. | R | 0 rejected tokens | Should | M-02 |
| 4.2-05 | Every consumer has the narrowest role. | R | 1 role per consumer | Must | 1.5-01 |