When AI Agents Act On Their Own, Infrastructure And Security Need One Accountable Owner
Jake Hammock, former CISO for the City of Seattle, explains how unified teams and risk-based metrics prepare organizations for agent-driven operations.

Make The Security Digest one of your go-to sources on Google
When autonomous agents rotate credentials and change firewall rules on their own, there's no longer a separate infrastructure decision and security decision.
AI agents can now rotate credentials and change firewall rules without waiting for human approval. Those changes fall under both the infrastructure team and the security team. When the two functions report to different leaders, no one clearly owns an agent's action if it goes wrong, and organizations often discover that gap in the middle of an incident.
Jake Hammock is a Cybersecurity and Technology Executive with more than 16 years of experience leading security and infrastructure teams. He began his career as a U.S. Army Military Intelligence and Cyber Warfare Officer supporting U.S. Cyber Command and the National Security Agency. He later held CTO and CISO roles in telecom, SaaS, fintech, and energy. Most recently, he served as Chief Information Security Officer and Assistant CTO for Security and Infrastructure at the City of Seattle, where he helped lead a division spanning cybersecurity, identity, networks, cloud operations, and telecommunications under a single program. Agents acting on their own have only made the case for that structure stronger.
"When autonomous agents rotate credentials and change firewall rules on their own, there's no longer a separate infrastructure decision and security decision. It's one decision, and it needs one accountable owner," Hammock says. Security leaders have debated for decades whether the security team should report into IT or stand apart from it. Agents reshape that debate. An agent can update a system in seconds, which leaves no time to route the work through two teams for review.
Everyone's on security
Large public organizations rarely run as a single entity. A major city can have dozens of departments, and a state government can have even more. "Most of these departments run autonomously. They have their own budget authority and their own legislative priorities," Hammock notes. Whether in government or in an enterprise with independent business units, security progress depends on department leaders trusting the central team enough to let it inside their operations.
That trust has to reach the engineers doing the work, too. Many security programs are moving toward continuous threat exposure management (CTEM). In this approach, teams prioritize and fix exposures across the environment on an ongoing basis, and remediation belongs to the people who run each system. Under that model, network engineers, telecommunications teams, cloud and Unix operators, middleware engineers, and enterprise architects all take on security work as part of their jobs.
"When you move from centralized vulnerability management to decentralized continuous threat exposure management, you flip the entire program on its head so that everyone becomes security. Welcome to the party. You're all cyber now. That's a hard sell, especially if people weren't hired to do that job," he adds. Buy-in comes more easily when security is part of the targets engineers already have. One way to do that is to write security into team standards and measure staff against them. For example, if a team's goal is to deploy three new applications by the end of the quarter, it only counts as met if each application passes security testing and is built from a golden image, a pre-approved template with security settings already in place. Because security is written into the deadline, engineers treat it as part of finishing the job.
Scoring real risk
Once security is built into everyone's work, leaders need to show that it's making a difference. The clearest way is to measure security by what it protects. Pointing to compliance rules or the risk of regulatory fines rarely motivates department leaders or engineers. Showing how security safeguards revenue is more persuasive for a company. For a city, the equivalent is public trust, meaning residents' confidence that essential services will keep running. "I don't really care about the volume of vulnerabilities we've mitigated. I care whether we mitigated them in time to prevent a catastrophe, and whether I can tie a business dollar to that," Hammock says.
In practice, that means giving teams credit for steps that lower risk even when a flaw stays open. If a patch isn't available yet, a team can isolate the affected system from the rest of the network so attackers can't reach it. That work keeps the organization safer until a fix arrives, and the metrics should reflect it.
Tying security to dollars works at the program level, but it isn't a tool for grading individual engineers. In Seattle, staff reviews looked at two things. The first was whether engineers deployed security controls the way the standard required. The second was whether they automated their procedures, so the team could spend less time reacting to emergencies.
To track overall progress, the division built its own cyber health index. The index scored the City's security on a scale of 0 to 100, using the NIST Cybersecurity Framework 2.0 and automated data feeds. A perfect score was never the target. The index gave leaders a consistent view of where the City stood, tailored to its own mission. Hammock expects more CISOs to build scoring models designed around their own operations.
Humans in the lead
As AI becomes part of most security tools, the people overseeing those tools matter more. The shift is a move from humans in the loop to humans in the lead. In that model, people set the direction and limits that agents work within. That role calls for different skills than security operations required 15 years ago, when teams relied on antivirus software and early intrusion detection. At the City, the answer was to invest in staff before adding new tools. Employees received AI and risk management training, and leaders gave teams time to experiment and design their own solutions.
As agents take on more daily operations, the people supervising them need to understand both the systems being changed and the security risks those changes create. Every organization's environment is different, so teams also need people who can adapt their tools to fit it. That kind of judgment takes time to build, and organizations need it in place before agents start making changes on their own. "Invest in your people and create space in your organization for creative thinking and reasoning," Hammock says.






