Kunstmatige intelligentie stimuleert een enorme verschuiving in de productiviteit van ondernemingen, van de code -voltooiingen van GitHub Copilot tot chatbots die interne kennisbasis mijnen voor directe antwoorden. Elke nieuwe agent moet authenticeren bij andere diensten, waardoor de bevolking van niet -menselijke identiteiten (NHI’s) stilletjes wordt gezworen in zakelijke wolken.
Die bevolking is al overweldigend de onderneming: veel bedrijven jongleren nu tenminste 45 machine -identiteiten voor elke menselijke gebruiker. Service -accounts, CI/CD -bots, containers en AI -agenten hebben allemaal geheimen nodig, meestal in de vorm van API -toetsen, tokens of certificaten, om veilig verbinding te maken met andere systemen om hun werk te doen. Gitguardian’s State of Secrets Sprawl 2025 -rapport onthult de kosten van deze wildgroei: over 23,7 miljoen geheimen Alleen al in 2024 opdook op Public GitHub. En in plaats van de situatie beter te maken, stelden repositories met Copilot het lek van geheimen mogelijk 40 procent vaker.
NHI’s zijn geen mensen
In tegenstelling tot mensen die zich aanmelden bij systemen, heeft NHI’s zelden enig beleid om rotatie van inloggegevens, strak scope -machtigingen of ongebruikte rekeningen te maken. Onbeheerd achtergelaten, weven ze een dicht, ondoorzichtig web van verbindingen met een hoog risico dat aanvallers kunnen exploiteren lang nadat iedereen zich herinnert dat er ge geheimen bestaan.
De goedkeuring van AI, vooral grote taalmodellen en ophalen-augmented generatie (RAG), heeft de snelheid en het volume aanzienlijk verhoogd waarmee deze risico-inducerende wildgroei kan optreden.
Overweeg een interne ondersteuning chatbot aangedreven door een LLM. Op de vraag hoe u verbinding kunt maken met een ontwikkelingsomgeving, kan de BOT een confluence -pagina ophalen met geldige referenties. De chatbot kan onbewust geheimen blootleggen aan iedereen die de juiste vraag stelt, en de logboeken kunnen deze info gemakkelijk lekken naar degene die toegang heeft. Erger nog, in dit scenario vertelt de LLM uw ontwikkelaars om deze platte tekstuele referentie te gebruiken. De beveiligingsproblemen kunnen snel opstapelen.
De situatie is echter niet hopeloos. In feite, als de juiste governance -modellen worden geïmplementeerd rond NHIS- en Secrets Management, kunnen ontwikkelaars daadwerkelijk innoveren en sneller implementeren.
Vijf bruikbare controles om AI -gerelateerd NHI -risico te verminderen
Organisaties die de risico’s van AI-gedreven NHI’s willen beheersen, moeten zich richten op deze vijf bruikbare praktijken:
- Audit en ruim gegevensbronnen op
- Centraliseer uw bestaande NHIS -management
- Voorkom geheimen lekken in LLM -implementaties
- Logboekbeveiliging verbeteren
- Beperk AI -gegevenstoegang
Laten we elk van deze gebieden nader bekijken.
Audit en ruim gegevensbronnen op
De eerste LLM’s waren alleen gebonden aan de specifieke gegevenssets waarop ze werden getraind, waardoor ze nieuwigheden zijn met beperkte mogelijkheden. Ophalen-augmented Generation (RAG) Engineering heeft dit gewijzigd door LLM toe te staan toegang te krijgen tot extra gegevensbronnen als dat nodig is. Helaas, als er in deze bronnen geheimen aanwezig zijn, lopen de gerelateerde identiteiten nu het risico misbruikt te worden.
Gegevensbronnen, waaronder projectmanagementplatform JIRA, communicatieplatforms zoals Slack en KnowledgeBases zoals Confluence, zijn niet gebouwd met AI of geheimen in gedachten. Als iemand een API -sleutel van platte tekst toevoegt, zijn er geen waarborgen om hen te waarschuwen dat dit gevaarlijk is. Een chatbot kan gemakkelijk een secrets-lekkende motor worden met de juiste aanwijzing.
De enige trefzekere manier om te voorkomen dat uw LLM die interne geheimen lekt, is door de aanwezige geheimen te elimineren of op zijn minst alle toegang in te trekken die zij hebben. Een ongeldige referentie brengt geen onmiddellijk risico met zich mee. In het ideale geval kunt u deze instanties van elk geheim helemaal verwijderen voordat uw AI het ooit kan ophalen. Gelukkig zijn er tools en platforms, zoals Gitguardian, die dit proces zo pijnloos mogelijk kunnen maken.
Centraliseer uw bestaande NHIS -management
Het citaat “Als u het niet kunt meten, kunt u het niet verbeteren” wordt meestal toegeschreven aan Lord Kelvin. Dit geldt zeer voor niet-menselijke identiteitsbeheer. Zonder de balans op te nemen van alle servicerekeningen, bots, agenten en pijpleidingen die u momenteel hebt, is er weinig hoop dat u effectieve regels en scopes kunt toepassen rond nieuwe NHI’s die verband houden met uw agentische AI.
Het enige dat al die soorten niet-menselijke identiteiten gemeen hebben, is dat ze allemaal een geheim hebben. Hoe je NHI ook definieert, we definiëren allemaal authenticatiemechanismen op dezelfde manier: het geheim. Wanneer we onze voorraden door deze lens concentreren, kunnen we onze focus instorten op de juiste opslag en beheer van geheimen, die verre van een nieuwe zorg is.
Er zijn tal van hulpmiddelen die dit haalbaar kunnen maken, zoals Hashicorp Vault, Cyberark of AWS Secrets Manager. Zodra ze allemaal centraal worden beheerd en verantwoord, kunnen we overstappen van een wereld van langlevende referenties naar een in de buurt waar rotatie wordt geautomatiseerd en gehandhaafd door beleid.
Voorkom geheimen lekken in LLM -implementaties
Model Context Protocol (MCP) -servers zijn de nieuwe standaard voor hoe Agentic AI toegang heeft tot services en gegevensbronnen. Eerder, als u een AI -systeem wilt configureren om toegang te krijgen tot een bron, zou u het zelf moeten bedraden en het uitzoeken als u gaat. MCP introduceerde het protocol dat AI kan verbinding maken met de serviceprovider met een gestandaardiseerde interface. Dit vereenvoudigt dingen en vermindert de kans dat een ontwikkelaar een inloggegevens hardcodeert om de integratie te laten werken.
In een van de meer alarmerende artikelen die de Gitguardiaanse beveiligingsonderzoekers hebben vrijgegeven, ontdekten ze dat 5,2% van alle MCP -servers die ze konden vinden ten minste één hardcode geheim bevatten. Dit is met name hoger dan het optreden van 4,6% van blootgestelde geheimen waargenomen in alle openbare repositories.
Net als bij elke andere technologie die u implementeert, kan een ounce van waarborgen vroeg in de levenscyclus van de softwareontwikkeling een pond incidenten later voorkomen. Het vangen van een hardcode geheim wanneer het nog steeds in een functietak zit, betekent dat het nooit kan worden samengevoegd en naar de productie kan worden verzonden. Het toevoegen van Secrets Detection aan de Workflow van de ontwikkelaar via GIT Hooks of Code Editor -extensies kan betekenen dat de inloggegevens van platte tekst nooit eens de gedeelde repo’s bereiken.
Verbeter de logboekbeveiliging
LLMS zijn zwarte dozen die verzoeken aannemen en probabilistische antwoorden geven. Hoewel we de onderliggende vectorisatie niet kunnen afstemmen, kunnen we ze vertellen of de uitvoer is zoals verwacht. AI -ingenieurs en machine learning -teams loggen alles van de eerste prompt, de opgehaalde context en de gegenereerde reactie om het systeem af te stemmen om hun AI -agenten te verbeteren.
Als een geheim wordt blootgesteld in een van die geregistreerde stappen in het proces, heb je nu meerdere kopieën van hetzelfde gelekte geheim, waarschijnlijk in een tool of platform van derden. De meeste teams slaan logboeken op in cloud -emmers zonder instelbare beveiligingscontroles.
Het veiligste pad is om een stepstap toe te voegen voordat de logboeken worden opgeslagen of verzonden naar een derde partij. Dit kost wat technische inspanningen om op te zetten, maar nogmaals, tools zoals GGShield van Gitguardian zijn er om te helpen met het scannen van geheimen die programmatisch kunnen worden ingeroepen vanuit elk script. Als het geheim wordt geschrobd, wordt het risico sterk verminderd.
Beperk AI -gegevenstoegang
Moet uw LLM toegang hebben tot uw CRM? Dit is een lastige vraag en zeer situationeel. Als het een interne verkooptool is die achter SSO is vergrendeld die snel notities kan zoeken om de levering te verbeteren, kan het goed zijn. Voor een chatbot voor klantenservice op de voorpagina van uw website is het antwoord een firma nee.
Net zoals we het principe van het minste privilege moeten volgen bij het instellen van machtigingen, moeten we een soortgelijk principe van de minste toegang toepassen voor elke AI die we implementeren. De verleiding om gewoon een AI -agent volledige toegang tot alles te verlenen in de naam van snelheidsoverzicht is heel geweldig, omdat we niet willen boksen in ons vermogen om te vroeg te innoveren. Het verlenen van te weinig toegang verslaat het doel van voddenmodellen. Het verlenen van te veel toegang nodigt uit dat misbruik en een beveiligingsincident wordt uitgeoefend.
Verhoog het bewustzijn van de ontwikkelaar
Hoewel we niet op de lijst zijn begonnen, is al deze begeleiding nutteloos tenzij je het bij de juiste mensen krijgt. De mensen op de frontlinie hebben begeleiding en vangrails nodig om hen te helpen efficiënter en veiliger te werken. Hoewel we wensen dat er hier een magische technische oplossing te bieden was, is de waarheid dat het bouwen en inzetten van AI veilig op schaal vereist dat mensen nog steeds op dezelfde pagina komen met de juiste processen en beleid.
Als u aan de ontwikkelingskant van de wereld staat, moedigen we u aan dit artikel met uw beveiligingsteam te delen en hun mening te krijgen over hoe u AI veilig kunt bouwen in uw organisatie. Als u een beveiligingsprofessional bent die dit leest, nodigen wij u uit om dit te delen met uw ontwikkelaars en DevOps -teams om het gesprek te bevorderen dat AI hier is, en we moeten veilig zijn als we het bouwen en ermee bouwen.
Het beveiligen van machine -identiteit is gelijk aan veiligere AI -implementaties
De volgende fase van AI-adoptie zal behoren tot organisaties die niet-menselijke identiteiten behandelen met dezelfde strengheid en zorg als zij menselijke gebruikers. Continue monitoring, levenscyclusbeheer en robuuste geheimen moeten een standaard operationele procedure worden. Door nu een beveiligde basis te bouwen, kunnen ondernemingen hun AI -initiatieven vol vertrouwen schalen en de volledige belofte van intelligente automatisering ontgrendelen, zonder de beveiliging op te offeren.
