Enterprise security is being reshaped by the same forces transforming how software is built. AI-assisted development and agent-driven workflows are accelerating output across organisations, generating more code, more configurations, and more digital artefacts than traditional security models were designed to handle. As engineering velocity increases, the gap between creation and protection continues to widen.
That imbalance has made one shift unavoidable: security can no longer sit downstream of development. It has to move closer to where systems are conceived and built.
“We are at this inflection point in how technology is changing jobs, processes, and how we approach problems,” says Neha Rungta, Director of Applied Science at AWS Identity. “One of the ways we think about the future is by looking at the past.”
She draws parallels with earlier technology transitions, noting that similar anxieties accompanied the rise of computing and automation. “When computers first came out, there was this fear that everybody would be jobless,” she says. “Instead, it changed how we work and created whole new layers of industry.” The same pattern, she argues, is now playing out with AI and agents. “We really believe that’s the inflection point we’re at today — in how we operate and how we do things.”

That change is already visible in software development, where coding assistants are increasing output, but it is also extending beyond IT. Organisations are beginning to explore agents in areas such as manufacturing and operations. With that expansion comes a structural challenge. “Security was already stretched thin in the IT age,” Rungta says. “Now, with coding assistance generating more code and more artefacts, that challenge has become even bigger. There’s no way humans can keep up.”
Despite this reality, most enterprise security investment remains reactive. “Today there’s roughly an 80/20 split,” she explains. “Eighty per cent of security spend happens on the reactive side.” By the time controls are triggered, damage has often already been done. “Reacting to bad actors and evolving threats is a treadmill we’re not going to be able to keep up with.”
AWS’s response is to flip that model. “We want to turn that 80/20 split on its head and move towards proactive security,” Rungta says. That means embedding security into the entire development lifecycle — not as a gate at the end, but as a continuous presence. “Starting from the idea itself — what does security mean for this system? Then as the design develops, as implementation happens, as it’s continuously tested — that’s where security needs to live.”
This shift is inseparable from changes in identity and access. Identity, Rungta notes, is no longer static. “People play different roles, systems interact across environments, and nothing should be trusted by default.” Applying Zero Trust principles consistently across that landscape is complex, particularly as organisations adopt agent-based systems that interact autonomously.
Automation has helped address part of that complexity by grounding trust in deterministic foundations. AWS’s Cedar policy language, for example, provides a common authorisation model across containers, agents, and services. “Where we’ve made strides is in defining what good looks like,” Rungta says. “We’ve defined patterns that allow systems to interact securely and correctly at scale.”
Adoption, however, remains critical. “It’s only as good as when somebody uses it,” she acknowledges. “Someone could still build a system with non-deterministic authorisation. Nothing physically stops that.” Over time, behaviour shapes the ecosystem. “If you say, ‘I’m only going to interact with systems that satisfy this model,’ that behaviour drives more systems to comply.”
She likens the moment to the early debates around web security certificates. “Twenty years ago, this was a hot topic — whether certificates were necessary or too much regulation,” she says. “Now we don’t think about it.” The same normalisation, she believes, will happen for AI agents and distributed systems.
A key part of making that transition work is avoiding rigid constraints. “If you create hard boundaries, you stifle innovation,” Rungta says. Instead, she advocates deterministic but adaptable controls. An agent processing insurance claims, for example, shouldn’t require human review for every decision. “You may want thresholds — below a certain amount, claims can be processed automatically; above that, they need review.” Those thresholds can evolve. “That’s what I mean by soft boundaries. You can tighten or loosen them as you learn.”
Ease of use remains central to whether security controls are adopted. “If you do security right, you shouldn’t have to make a trade-off between ease of use and security,” Rungta says. Tools such as Block Public Access were designed with that philosophy in mind. “Ninety-nine point nine per cent of buckets don’t need to be public,” she says. “So we made it a single declarative control, and eventually it became the default.”
The same approach applies to visibility tools such as access analysis. “It shows you who has cross-account access,” she explains. “You can look at it and say, ‘This person was a contractor six months ago — they shouldn’t have access anymore.’” The goal is to surface risk clearly rather than bury users in policy complexity. “Confusion is actually worse than friction when it comes to security.”
These principles come together in AWS Security Agent, which is designed to bring security checks directly into development workflows. “We’ve been using it internally for the past few months for design reviews and code reviews,” Rungta says. “What we’re finding is that it allows us to scale security knowledge across large parts of the organisation, right where people are building.”
Rather than replacing human judgement, the agent codifies organisational requirements and applies them consistently. “The human-driven part of security moves up a level,” she explains. “It becomes about intent — not about manually checking architectures, outdated libraries, or individual vulnerabilities.”
In its current form, the agent provides structured feedback, such as commenting on pull requests and generating findings on design documents. That restraint is intentional. “We didn’t want it to be too noisy,” Rungta says. “If something is always there and too intrusive, people just want to turn it off.” For now, “the agent gives recommendations, and it’s up to the end user to implement them.”
Over time, as trust increases, deeper integration is possible — but always incrementally. “This isn’t about jumping straight to full automation,” she says. “It’s an iterative process, with humans still in the loop.”
Reactive security is not disappearing. Attacks continue to increase in volume and sophistication. But the balance is shifting. “Rather than just pouring more effort into reacting,” Rungta says, “we really believe it’s time to step back and ask how we make ourselves more secure by starting at the beginning.”






Discussion about this post