I use AI to write code, and I am not giving it up. Neither should your engineering teams. Teams are adopting AI assistance to ship faster, and that shift is not reversing. That is exactly why the security problem underneath it deserves a clear look. AI-assisted development can introduce hardcoded secrets and expand the number, privilege, and reach of the non-human identities working across your delivery pipeline. Most organizations are not governing either one, and that gap is where the next wave of breaches is forming.
None of this argues for slowing down. It argues for governing what AI-assisted development creates, so the speed you gained does not turn into exposure you never priced in.
The risk is not one thing. AI-assisted development expands risk in three connected but distinct places. The generated code can carry security defects. Prompts, repositories, logs, and output can expose credentials, in both directions. And the agents reaching your source control, cloud services, and data need identities with carefully bounded permissions. A secret scanner does not fix an over-permissioned agent, and least privilege does not catch insecure application logic. You have to govern all three.
How does AI-assisted development expose secrets?
AI-assisted development exposes secrets because the models reproduce the patterns they learned from, and public code is full of hardcoded credentials. When an assistant generates a working example, it can embed an API key, a connection string, or a token directly in the code, especially when the prompt, the repository context, or the surrounding code already normalizes that pattern. The code runs. The secret can ship.
The data released in 2026 shows how fast this grew in 2025. GitGuardian's State of Secrets Sprawl 2026 counted more than 28 million new hardcoded secrets in public GitHub commits during 2025, a 34 percent jump and the largest single-year rise on record. Leaks tied to AI services rose 81 percent in a single year. In the same analysis, commits co-authored by one popular assistant, Claude Code, exposed secrets at 3.2 percent against a 1.5 percent baseline across all public commits. GitGuardian is careful about that number, and so am I. The leak still runs through a human workflow. Developers decide what to accept, edit, or push. The tool did not fail. The process around it did.
Two forces compound the problem. AI increases code volume and change velocity, which makes manual-only review less reliable as the primary control. And the exposure runs in both directions. An assistant can write a secret into code, and a developer can hand one to the assistant, pasting a production log, a config file, or an error trace full of tokens into a prompt. GitGuardian found that roughly 28 percent of secret incidents now originate outside code repositories entirely, in places like Slack, Jira, and Confluence, where credentials get shared during urgent troubleshooting. Any policy that governs only the code misses half the problem.
None of that is a reason to stop. It is a reason to assume AI-assisted work may contain secrets until a scan proves otherwise, and to govern both what the tools can reach and what people can submit.
Every AI coding agent needs a governed identity
Here is the part that sits squarely in my field. AI-assisted development is not only a code problem. It is an identity problem.
Every AI agent that reaches your environment does so through one or more non-human identities: a service account, an OAuth client, an API key, a certificate, or a short-lived token. A coding assistant, a build agent, a deployment bot, each authenticates as something, and the more work you hand it, the more entitlements it accumulates. In agentic and multi-agent workflows, one orchestrator can create or delegate to additional agents, multiplying credentials and audit paths as it goes.
This is not a fringe concern. Reports through 2026 put non-human identities at anywhere from around fifty to one hundred times the number of human identities in cloud-heavy environments, with the exact ratio depending on what gets counted. The World Economic Forum has called non-human identities the new frontier of agentic AI risk, and analysts increasingly treat AI agents as a distinct identity type that is neither fully human nor fully machine. I covered the governance side in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and AI-assisted development is where that blind spot turns operational.
The risk is not limited to the code an assistant suggests. Once an agent can read a repository, call tools, open tickets, invoke CI/CD, or connect through a Model Context Protocol server, it becomes an execution path into the enterprise. GitGuardian found more than 24,000 secrets sitting in Model Context Protocol configuration files on public GitHub, a pattern the setup instructions themselves often encourage. Add prompt injection delivered through a README, an issue, or a dependency's documentation, and the agent's permissions, allowed tools, and data boundaries need the same design discipline you give any privileged workload.
The uncomfortable pairing is this. AI writes code that leaks the very secrets these identities depend on, inside a system where the identities themselves are barely governed. Leaked credential, meet ungoverned identity. That is the attack path.
The productivity is real, so protect it
I want to be direct about where I stand, because the headline can read the wrong way. I am not arguing against AI-assisted development. I am arguing for keeping it.
The teams shipping with AI assistance are faster, and that advantage is not going back in the box. Telling engineers to slow down is both futile and wrong. The organizations that win will adopt aggressively and govern deliberately, and those two things are not in tension. Security is not the brake on AI development. It is what lets you keep your foot on the accelerator without wrapping the car around a tree.
Consider how a mature enterprise already treats any third-party dependency. You do not refuse open-source libraries because some carry vulnerabilities. You scan them, track them, patch them, and keep shipping. AI-generated code deserves the same posture. Treat it as untrusted input from a very fast contributor, verify it, and move on. That is not skepticism about AI. It is how you make AI safe to rely on at scale.
How do you secure AI-assisted development without slowing it down?
You secure it by governing the two things AI development produces, code and identities, with controls that run at machine speed instead of human speed. The goal is not more meetings. It is automation that keeps pace with the tools creating the risk.
A practical program rests on a few moves:
- Scan for secrets continuously, in the pipeline and beyond it. Run detection on every commit and every AI-assisted change, and extend it to the tickets, chat, and logs where secrets also land. Removing a key from code is not enough, since it can be recovered from history, so rotate or revoke it too.
- Give every agent its own scoped identity. No shared keys, no borrowed service accounts, outside narrow legacy exceptions you document and monitor. Each agent gets a named identity with least-privilege access to only what its task requires.
- Prefer short-lived, dynamically issued credentials. Replace long-lived static keys with tokens that expire in minutes where the platform supports it. A leaked credential that has already expired is close to a non-event.
- Keep an owned inventory of non-human identities. Every agent and service account needs a human owner, a documented purpose, and a decommission date. Unowned identities are where risk hides.
- Treat AI output as an untrusted contribution, and do not stop at review. Apply the same supply-chain controls you use elsewhere: dependency and infrastructure-as-code scanning, branch protections, code-owner review for anything touching authentication, authorization, cryptography, payments, data access, or deployment, and an audit trail that ties each material change to a user, an agent, and an identity.
These controls shift the security work from a late, manual gate to an early, automated one, which is the only model that survives contact with AI-speed development. Integrated into developer workflows, they cut late-stage rework instead of adding a release bottleneck, and they keep most of AI's delivery advantage while slashing the cost of remediation.
Detection without revocation is not remediation, and the data proves it. GitGuardian retested credentials it first confirmed valid in 2022 and still found more than 64 percent of them live in 2026. When a secret surfaces, rotate or revoke it, trace where it was used, assess what it could reach, and fix the control at the point it entered the workflow.
Where you sit on this path matters more than doing everything at once:
| Stage | Minimum standard |
|---|---|
| Pilot | Approved tool list, no production secrets in prompts, user-level attribution, basic secret scanning |
| Team rollout | SSO and SCIM, repository and data-access boundaries, CI secret scanning, branch protections, named owners for service accounts |
| Enterprise scale | Short-lived federated workload identity, centralized secrets management, agent and tool allowlists, full audit logging, revocation workflows, continuous entitlement review |
This is also where the commercial conversation lives, and it is rarely a technical failure that stalls these programs. It is that the person who sees the risk cannot translate it into a consequence the budget holder acts on. I worked through that exact dynamic in Why Identity Risk Loses the Budget Conversation, and it applies directly here. Frame AI governance as protecting the productivity leadership already values, and you get funded. Frame it as a brake, and you do not.
I write about where identity security and commercial strategy meet, because in AI-assisted development they are the same conversation. If your organization is working through this, connect with me on LinkedIn.
Frequently asked questions
Is AI-generated code less secure than human-written code?
Not inherently, but it should not be presumed secure. Results vary by model, prompt, language, task, and review process. A 2026 study across six leading models reported confirmed vulnerabilities in about a quarter of generated samples, while earlier research on one popular assistant found security weaknesses in roughly 40 percent of the scenarios tested. Those figures need their methodology to mean anything, and they do not add up to a universal defect rate. The operational answer is to test and review AI output under the same controls, or stronger ones, that you apply to any untrusted contribution.
What is a non-human identity in AI development?
It is the identity assigned to software, a workload, a service, a bot, a pipeline, or an AI agent, so it can authenticate and act without an interactive human login. Its authenticator might be a service account, a workload identity, an OAuth client, a certificate, an API key, or a short-lived token. The governance questions that matter are who owns it, what it can access, how long it lasts, how its activity is logged, and how it gets revoked.
Can developers paste production code or error logs into a coding assistant?
Only if your organization has approved the tool, understands its data-handling terms, and has defined what may be submitted. Production secrets, customer data, private keys, and regulated information should be blocked or redacted before they reach a prompt. The same policy should cover repository-context features and tool integrations, not just the chat box.
What should happen when a secret shows up in AI-assisted code?
Treat it as an incident, not a text edit. Revoke or rotate the credential, determine whether it was used, assess the access it carried, remove it from active code and configuration, and add or tune the control that should have caught it before production.
How do we let developers use AI without creating security debt?
Automate the controls so they run at the speed of the tools. Scan every change and channel for secrets, scope each agent to least privilege, expire credentials quickly, and review AI output like any third-party dependency. That keeps the productivity while closing the exposure.
The speed is worth keeping
AI-assisted development is one of the most significant productivity shifts enterprise engineering has seen, and the organizations leaning into it are right to. The mistake is treating the speed as free. It arrives with generated code that needs verifying, secrets that need detecting and rotating, and machine identities that need scoping, ownership, and observation, and the companies that build those habits early will keep their advantage while others clean up breaches they could have prevented.
AI is writing your code, and yes, it can leak your secrets. That is a solvable problem, and solving it does not mean making developers wait. Make secure behavior the default: credentials injected at runtime instead of written into code, short-lived access instead of permanent keys, and automated checks that catch problems before production. Govern the identities, protect the context, scan the code and the secrets, and let your teams keep building at the speed the tools finally made possible.
Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.
Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne
