Turnkey introduceert Managed Secrets voor toegang tot inloggegevens van AI-agenten

Turnkey heeft Managed Secrets gelanceerd. Daarmee breidt het bedrijf zijn op beveiligde enclaves gebaseerde walletinfrastructuur uit naar de API-sleutels, wachtwoorden, betaalgegevens en herstelgegevens die applicaties en AI-agenten nodig hebben. Met de aankondiging van 29 oktober begeeft het bedrijf zich buiten het beheer van privésleutels en richt het zich op een breder probleem: software de bevoegdheid geven om handelingen uit te voeren zonder herbruikbare inloggegevens overal in de infrastructuur te verspreiden.

Met het product kunnen teams bepalen welke service een inloggegeven mag ophalen en of daarvoor menselijke goedkeuring of goedkeuring door meerdere partijen nodig is. Voor financiële applicaties kan dat betekenen dat een geautoriseerde handelsbackend een API-sleutel voor een beurs krijgt, terwijl die sleutel buiten het gesprek en de uitvoeringsomgeving van een AI-assistent blijft.

Toegang tot inloggegevens verplaatsen naar een beveiligde enclave

Inloggegevens in omgevingsvariabelen of configuratiebestanden zijn handig voor software, maar als het proces dat ze uitleest wordt gecompromitteerd, kunnen ze worden blootgelegd. Een kluis kan opslag en toegangsbeheer centraliseren. De resterende vraag is waar een inloggegeven leesbaar wordt en welke systemen op dat moment moeten worden vertrouwd.

Managed Secrets voert de autorisatiecontroles uit binnen de beveiligde enclaves van Turnkey. Een client versleutelt een geheim voordat het wordt geïmporteerd, waarna de enclave het opnieuw versleutelt voor opslag. Wanneer er een verzoek binnenkomt, beoordeelt de enclave het toepasselijke beleid en de vereiste goedkeuringen voordat het resultaat wordt versleuteld met de sleutel van de beoogde ontvanger. De aanvrager en de ontvanger kunnen verschillende services zijn.

Die scheiding is belangrijk. Een applicatie kan werk in gang zetten en goedkeuringen verzamelen zonder de mogelijkheid te krijgen om het inloggegeven te ontsleutelen dat nodig is om het werk uit te voeren. De handtekening van een goedkeurder geeft toestemming voor vrijgave, maar verleent niet automatisch toegang tot het vrijgegeven geheim.

De cryptografie achter import en export

In de documentatie over het beveiligde kanaal van Turnkey wordt een protocol beschreven dat is gebaseerd op Hybrid Public Key Encryption (HPKE). Het combineert sleutelovereenkomst op basis van openbare sleutels met geauthenticeerde versleuteling, zodat gevoelige gegevens als cijfertekst via tussengelegen systemen kunnen worden verstuurd. Tijdens het importeren controleert de client het door de enclave ondertekende sleutelmateriaal; bij het exporteren wordt versleuteld met een openbare sleutel die in het ondertekende verzoek is opgegeven.

Ontvangstsleutels zijn bedoeld voor eenmalig gebruik. Turnkey merkt op dat clients zich zelf aan die regel moeten houden: het protocol kan niet voorkomen dat een gebrekkige client de doelsleutel opnieuw gebruikt. De implementatie aan de clientzijde maakt daarmee, net als de enclave, deel uit van het beveiligingsmodel.

Op de productpagina van Managed Secrets staat dat elk geheim afzonderlijk wordt versleuteld met AES-256-GCM wanneer het is opgeslagen. De API ondersteunt zowel afzonderlijke inloggegevens als verzoeken voor meerdere geheimen. Exports van meerdere geheimen mislukken in hun geheel als voor een van de opgevraagde geheimen geen toestemming is verleend. Zo wordt voorkomen dat een gedeeltelijk goedgekeurde bundel wordt vrijgegeven.

Waarom de ontvanger nog steeds van belang is

De uitspraak ‘agenten kunnen inloggegevens gebruiken zonder ze te zien’ beschrijft een integratiepatroon, geen garantie dat elk ontvangend proces geen toegang tot de onversleutelde gegevens kan krijgen. In de documentatie voor ontwikkelaars van Turnkey staat uitdrukkelijk dat onversleutelde gegevens zowel binnen de enclave als op de client die een geheim importeert of exporteert aanwezig kunnen zijn.

Als een afzonderlijke uitvoeringsservice de sleutel van de ontvanger in bezit heeft, kan die service een inloggegeven ontsleutelen en gebruiken zonder het aan het model bloot te stellen. Heeft de eigen runtime van de agent die sleutel in bezit, dan kan die runtime het gegeven ontsleutelen. Daarom blijft het noodzakelijk om de ontvanger, diens geheugen en diens logboeken te beveiligen.

Er is nog een tweede grens: beleid kan de context van een verzoek controleren, zoals een opgegeven domein voor het afrekenen, maar Turnkey verifieert niet zelfstandig of die bewering klopt. Een ondertekende bewering legt vast wie deze heeft gedaan. Applicaties hebben nog steeds betrouwbare controles nodig die de bewering koppelen aan de daadwerkelijke handeling.

Goedkeuringen die met een workflow kunnen meegroeien

Teams kunnen ophalen rechtstreeks toestaan, menselijke goedkeuring van een verzoek vereisen of overeenstemming tussen meerdere agentrollen verplicht stellen. Het beleid kan worden aangepast zonder het onderliggende geheim opnieuw te importeren. Zo kan een workflow beginnen onder nauw toezicht en kunnen later bepaalde verzoeken worden geautomatiseerd.

In de handleiding voor programmeerbare toegang van Turnkey wordt getoond hoe een browseragent en een betalingsagent samen een verzoek ondertekenen. Alleen de betalingsagent ontvangt kaartgegevens die kunnen worden ontsleuteld. Voordat de browsercomponent het verzoek goedkeurt, controleert deze of het voorgestelde domein overeenkomt met de pagina die hij gebruikt. Het voorbeeld laat zien waarom onafhankelijke rollen en validatie belangrijker zijn dan simpelweg twee goedkeuringen tellen.

Agentrollen kunnen gebruikmaken van tijdelijke sessiegegevens met beperkte bevoegdheden, zodat beheerders één actieve instantie kunnen intrekken. Toekomstige toegang intrekken kan echter geen geheim wissen dat een ontvanger al heeft ontsleuteld. Het rouleren van inloggegevens verderop in de keten blijft een afzonderlijke operationele beveiligingsmaatregel.

Van walletinfrastructuur naar financiële automatisering

Turnkey’s bestaande beveiligingsarchitectuur maakt gebruik van AWS Nitro Enclaves en combineert hardwarematige isolatie met reproduceerbare softwarebuilds en attestatie op afstand. Dankzij reproduceerbaarheid kunnen softwarebuilds met elkaar worden vergeleken, terwijl attestatie bewijs levert over de code die in de enclave wordt uitgevoerd. Managed Secrets breidt deze basis uit naar andere inloggegevens dan blockchain-ondertekeningssleutels.

Het bedrijf noemt handelsfirma’s, fintech-backends, ontwikkelaars van AI-agenten en MPC-bewaarders als beoogde gebruikers. Inloggegevens voor beurzen en OAuth-tokens bieden doorlopende toegang tot diensten; back-ups van sleutelshares en herstelsleutels dragen bij aan de weerbaarheid. Het gaat om afzonderlijke toepassingen met verschillende vereisten voor goedkeuring en ontvangers, ook wanneer ze dezelfde opslaginfrastructuur gebruiken.

Voor fintechteams ligt de betekenis in een duidelijker onderscheid tussen het aanvragen van een handeling, het autoriseren van toegang en het ontvangen van een bruikbare inloggegeven. Managed Secrets biedt infrastructuur voor die scheiding. De bescherming hangt af van strikt afgebakende beleidsregels, betrouwbare goedkeurders en een goed beveiligde dienst die het geheim uiteindelijk gebruikt.