CSO Online

AI agents’ actions are out of scope for new guidance from US authorities on securing identity and access tokens, but there is still plenty enterprises can do to protect their systems from rogue humans and AI agents alike. “Protecting Tokens and Assertions from Forgery, Theft, and Misuse,” a new report from the National Institute of Standards and Technology (NIST) with help from the Cybersecurity and Infrastructure Security Agency (CISA), offers guidance for operators of systems that use digitally signed tokens to make access decisions, including single sign-on and API access. The guidelines, also known as NIST IR 8587, address what happens after authentication: Tokens and assertions can carry proof of authentication or authorization between systems, allowing an attacker who compromises them to exploit access that has already been granted. NIST recommends continuous monitoring, along with tighter controls throughout the token lifecycle. The issue is of particular significance for CISA. In May, a public GitHub repository believed to have been maintained by a CISA contractor was found to contain sensitive government credentials, including AWS tokens and GitHub access tokens. CISA said at the time there was no indication that sensitive data had been compromised. ## The unresolved question of agent authority NIST recommends applying the same guidelines for securing signed tokens used by AI agents as for securing those used by humans, but notes that the access risks posed by AI and AI agents “create additional IAM challenges that require further guidelines and, in some cases, new or expanded standards and protocols.” NIST and CISA are still working on those, but there are things that IT teams can do meanwhile to secure agentic systems. Managing the lifecycle of an agent’s identity is part of the challenge, said Yih Khai Wong, senior research manager for security services at IDC Asia/Pacific. Enterprises need visibility into who provisioned an agent’s credentials and what those credentials allow, Wong said. Access should also be withdrawn when the agent’s task ends. “Token hardening assumes the token holder is a known, bounded actor,” Wong said. “An agentic system breaks that assumption.” Delegation can make that boundary harder to establish, said Amit Kumar Jena, head of AI development at Kanerika. An agent may act on behalf of a user, invoke a tool and then reach another service, making it increasingly difficult to determine whose authority is being exercised as the chain grows. Jena said prompt injection could also steer an agent holding a valid token toward an action the user never requested. Token verification would not necessarily detect that misuse because the token itself could still be legitimate. Jain argued that CISOs should treat AI agents as low-trust non-human identities, granting only the access required for a task. Higher-risk actions should require human approval, he added. Wong also recommended maintaining an agent inventory and keeping those identities separate from human accounts. Credentials should expire when the task is complete, he said. ## Why valid tokens can still be dangerous A common weakness is assuming that because a token is valid, the activity associated with it is legitimate, according to Jonathan Ong, senior analyst for managed security services at Omdia. Organizations should consider the context in which a token is presented, including whether a user is accessing sensitive systems from an unusual location or at an unexpected time, Ong said. Detection should also correlate activity across security domains to identify behavior that may appear benign in isolation. Containment presents another challenge once a token has been compromised. “Token revocation may not always be possible due to architectural limitations,” Ong said. Other controls can limit the usefulness of a compromised token. Neil Shah, vice president for research and partner at Counterpoint Research, said that NIST’s recommendations can reduce both the duration and reach of a token compromise. Audience restrictions can limit where a stolen token is accepted, while cryptographically binding a token to the client holding the corresponding private key makes replay by an attacker more difficult. The report also points organizations toward shared-signal mechanisms such as the Continuous Access Evaluation Profile (CAEP) and Risk Incident Sharing and Coordination (RISC), which can help connected systems respond when token-related security conditions change, Shah said. ## Token security extends beyond IAM The CISA credential exposure also highlights how token security can break down outside traditional IAM controls, Jain said. Credentials can surface in source code, CI/CD pipelines, logs and contractor environments even when access policies themselves are sound. “If a contractor can copy a cloud credential to their local machine, the identity governance has already failed,” Shah said. Managing that risk through policy alone can be difficult in DevOps environments, where credentials can be copied onto developer machines or exposed through automated pipelines, Shah said. He argued that enterprises should eliminate static tokens wherever possible and replace them with short-lived credentials. The CISA incident also exposes a boundary in the NIST guidance, Jena said. IR 8587 focuses on asymmetrically signed tokens and explicitly places mechanisms such as API keys outside the scope of its controls. NIST nevertheless requires covered tokens to be kept out of logs, CI/CD pipelines, and build artifacts.

Organizations are investing more in security than ever before, yet many still struggle with a fundamental problem: they are preparing for tomorrow’s crisis with yesterday’s mindset. For decades, companies organized security around neat categories. Cybersecurity protected networks. Physical security protected facilities and people. Human resources managed workforce issues. Legal handled compliance. The model worked because threats largely stayed in their lanes. That is no longer the case. Today, AI-powered impersonation, deepfakes and automated social engineering are creating risks that move quickly across digital, physical and operational environments. A deepfake phone call can enable financial fraud. An online threat against an executive can become a physical security concern. A recent EY survey data of 250 corporate leaders and directors reveals that only 12% of organizations feel most prepared to detect a targeted physical attack. Bridging this gap requires an integrated approach across every step – detection, deterrence, prevention, preparation, response, mitigation, investigation and recovery — long before a situation escalates. ## Threats are changing faster than organizations One of the most common misconceptions about AI-driven threats is that they represent entirely new forms of risk. In reality, the underlying motives are familiar: fraudsters still want to steal money, and adversaries still seek sensitive information. What has changed is the execution. Throughout my career in forensic accounting and law enforcement, I watched criminal schemes evolve from basic fraud to complex international operations. The execution today is incredibly sophisticated, particularly around remote hiring. Transnational threat groups now deploy deepfakes and stolen identities to bypass virtual HR hiring loops. If your compliance and background diligence operate separately from your IT provisioning, you could end up physically shipping secure corporate hardware and handing network access straight to a thief or worse — a foreign adversary. Organizations can work to counter this by building unified, cross-functional verification pipelines that bridge HR, cyber provisioning and physical asset logistics from day one. ## Security teams still operate in silos While threats are becoming more interconnected, many security programs remain fragmented. Each function across cybersecurity, physical security, HR and legal may perform its role effectively, but risks arise when information is not shared seamlessly between them. Recently, I asked the leadership at a large organization what formal processes govern the relationship between their physical security teams and cybersecurity teams. The answer was revealing. The teams had “strong relationships” and “communicated regularly” but lacked documented processes, shared escalation procedures and clearly defined responsibilities during a crisis. Relationships are important, but they are not a substitute for a security program. When organizations rely primarily on informal communication, response efforts become dependent on individual personalities and availability at a particular moment — whether you are handling a volatile protest near corporate offices, a shooter in a facility or building a logistics plan to move 500 employees, technology and intellectual property out of a geopolitical conflict zone. If your departments rely on casual check-ins instead of integrated policies and shared tooling, precious time and operational flexibility may be lost when they are needed to mitigate a threat. ## The next evolution of security involves integration Over the last decade, boards and executive teams have invested heavily in cybersecurity. Organizations built security operations centers, established governance structures and developed incident response plans. This same approach should be applied more broadly across security and crisis management functions. That includes integrating cyber threat intelligence with physical threat monitoring, improving coordination between CISOs and chief security officers, and confirming crisis management plans account for a wider range of risks. Furthermore, human expertise should remain at the center of automated defenses. AI is highly effective at aggregating data, such as overlaying toolsets onto camera feeds to identify physical threats or tracking social media spikes regarding a terminated employee. But AI hallucinates. You need competent, qualified people evaluating that intelligence in real time before making major operational calls. The companies that make the most progress shift from an event-driven mindset to a threat-driven mindset. Rather than waiting for an incident to occur, they continuously assess emerging risks and make operational decisions before a situation escalates. ## Security is a core operational responsibility The convergence of cyber and physical threats is prompting organizations to rethink how security functions operate. If an organization’s cyber network gets breached, it is existential to the business. But if physical security fails, the result could be an irreparable tragedy. Organizations do not need a crystal ball to prepare for the future. They need stronger coordination, better communication and a clearer understanding that today’s threats rarely fit neatly into a single category. The companies that adapt fastest recognize a simple reality: attackers are already operating across digital and physical environments. Security teams need to do the same. That means breaking down silos to enable faster, more coordinated response times, where insights are shared in real time and decisions are made without delay. In this environment, speed is not just an advantage; it is a core requirement for resilience.

Yet another security vulnerability has been discovered in GitLab infrastructure, this one a perfect 10 in severity. CVE-2026-85706, the second flaw GitLab has disclosed in just a month, is a maximum-severity vulnerability that allows attackers to read arbitrary files in a single HTTP request. The path traversal flaw results from improper confinement and lack of authentication enforcement in GitLab’s repository commits API, the company reported. Threat actors could exploit it “under certain conditions” and read arbitrary files (credentials, secrets, and other sensitive data) on vulnerable GitLab servers. The company has fixed the vulnerability, which impacts GitLab Community Edition (CE) and Enterprise Edition (EE), and has advised customers with public-facing self-hosted GitLab instances to patch their servers immediately, or remove public access. Experts say the flaw is alarming because GitLab’s DevSecOps platform is used by roughly 50% of the Fortune 100 and has more than 50 million estimated registered users. “GitLab is not simply a source-code repository,” noted Safayat Moahamad, advisory director at Info-Tech Research Group. In many enterprises, it is connected to build pipelines, deployment processes, application security workflows, and other trusted systems. As a result, unauthorized access to configuration files, secrets, or credentials on the GitLab server could “create consequences well beyond the affected instance,” he said. ## Don’t wait for the normal patch cycle GitLab has been a favorite hacker target of late: In January, it patched a high-severity flaw that allowed attackers possessing a target’s account ID to bypass two-factor authentication, and in August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even completely delete them with a single HTTP request. The current maximum severity bug, CVE-2026-85706, was reported through GitLab’s HackerOne bug bounty program. It affected CE and EE versions 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, noting that this type of vulnerability is a frequent attack vector for malicious cyber actors, and particularly poses significant risks to the federal enterprise; watchTowr Intel has reported that it is already observing “in-the-wild probes.” “Based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away,” it warned. This is not a vulnerability that organizations should leave for the normal patch cycle, Moahamad emphasized. “It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows,” he said. Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, he advised. Beyond patching, the watchTowr Intel team said defenders should try to identify exploitation attempts by hunting through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters. ## CI/CD platforms are critical trust infrastructure Organizations running affected self-managed GitLab CE or EE instances should be most concerned, Moahamad noted. Risk increases where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes. The information and/or access that attackers could obtain depends on what the GitLab service can read and what organizations store on the server, he explained. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure “The flaw directly creates an unauthorized file access risk,” he said. Credential theft, lateral movement, source code exposure, and supply chain compromise are possible follow-on scenarios. Source code and CI/CD platforms must be governed as “critical trust infrastructure,” he said. While patching remains essential, resilience will depend on knowing where platforms can be exposed, limiting what they can access, detecting abnormal API behavior, and having a tested process for investigating and rotating credentials. David Shipley of Beauceron Security described two factors colliding to generate “maximum pain” for GitLab users. First is the vulnerability. “It’s a 10 for a reason: Unauthenticated read access to GitLab client source code,” he said. Second, this especially hurts because developers still have bad habits: way too much code continues to ship or is in production with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said. “So for attackers, you’ve got the classics,” he noted: Data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the stealing of AI tokens and infrastructure to enable other criminal activity. “This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number,” Shipley said. “It opens up a world of criminal data shopping.” The bottom line: “Get those secrets out of production code and adopt modern coding authentication best practices,” he advised.

AI dominated the conversation at Fal.Con 2026, but one of the most important takeaways wasn’t simply how AI is changing cyber defense. It was how AI is changing the speed and scale of a problem defenders already face. Security teams already have more vulnerabilities and security signals than they can reasonably act on. As AI makes it faster to discover vulnerabilities and determine whether they can be exploited, finding more weaknesses only makes one question more important: Which exposures actually matter in my environment? That question surfaced throughout Fal.Con. In his keynote, CrowdStrike CEO George Kurtz spoke about AI as the new cyber battlefield, offense informing defense, AI red teaming, and the need for a continuous approach to security. For defenders, that means moving beyond theoretical risk to understand what attackers can exploit in their specific environments. Can credentials be abused? Can weaknesses be chained together? Can attackers move laterally or escalate privileges? Can they reach critical systems or data? Answering those questions gives security teams evidence they can use to prioritize what matters most, remediate with clarity, and verify that their actions actually reduced exposure. As AI increases attacker speed and scale, that evidence becomes more important, not less. Read Horizon3’s full Fal.Con 2026 perspective on why AI is making exposure validation more critical than ever. ---

Microsoft is changing the destination address of two of its most popular services: starting this month, it will redirect M365 and Teams web users to copilot.cloud.microsoft and teams.cloud.microsoft, respectively. The Teams move is already under way, and Microsoft has now added M365 to the mix. The company announced the changes in two MessageCenter posts: MC1465764 (mirror) and MC1462915 (mirror). Organizations using these products are advised to update their systems and documentation to ensure continued access. Microsoft has told customers to review configurations on client devices, proxies, firewalls, secure web gateways, or other enterprise network controls to confirm that users can connect to the new addresses. Companies having trouble connecting should ensure that their environment aligns with the recommended network requirements for Microsoft 365 Copilot. Enterprises that had been blocking the new Copilot address to prevent employees accessing their personal Microsoft accounts can use Microsoft’s TenantRestrictions control to achieve their goals instead, it said. All redirects should be completed by early October, Microsoft said, advising companies that can’t meet the deadline to contact their account representative for help. Limited exceptions to the Teams redirect are possible until Dec. 31, 2026, but after that no further delays will be possible, it said. This article first appeared on Computerworld.