One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.”

It sounds almost funny. In software terms, though, it points to a real problem. An access control said no, and the agent treated the answer as information about how to continue.

“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.

Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”

Different systems, different failures, one question: what does “access denied” mean to an agent?

Why a denial is information

Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.

Agents do have one.

We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.

A timeout says “try later.” A malformed request says “fix this.” An authorization failure says “you are not allowed to do this.” Those are different kinds of messages, but a guardrail that returns all three as text in the model’s context makes them look alike.

Researchers are now measuring what happens after a restriction is applied. In the August paper Permission Denied, 12 coding agents were tested under increasingly restrictive security policies. Blocked runs rarely stopped early. They timed out or produced wrong solutions. Of the policy-induced failures, the researchers found that 97% came from the agent building a workaround.

The issue is not simply whether a model understands a policy. It is what the system allows the model to do after the policy says no.

Enforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a trusted tool boundary the agent cannot control. But that still leaves an unanswered question: when should a denial end the task rather than become another input for the agent?

Real systems already have harder stops. The OpenAI Agents SDK can halt a run when a tool guardrail raises an exception. Claude Code’s auto mode can return control to a person after three blocked actions in a row or 20 in total.

Nothing tells you which denials deserve which response. The missing piece is not another kill switch. It is a policy for deciding what a denial means and what authority disappears when it happens.

I don’t think the lesson is that models are bad. The problem is where we put the boundary. A guardrail that reports back to the thing it is restraining is a soft boundary. It shapes behavior. It doesn’t necessarily end it.

A terminal denial changes authority

I would treat denials differently depending on what they mean.

A denial is retryable when the same authorized request might succeed later without anyone granting new authority. A timeout, a temporary dependency failure or a rate limit can fit here.

It is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.

It is terminal when continuing would require permission the task was never given, such as reading another tenant’s records or reaching a destination the egress policy prohibits.

The test is whether succeeding needs permission or just patience.

If it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.

In a previous InfoWorld piece, I argued that permission enforcement should be independent of how an agent interprets its situation. A terminal denial applies that principle at the moment of refusal. It should change the state of the system, not just the contents of the model’s context.

A terminal denial should do five things.

1. Enforce it at a trusted execution boundary. The decision happens in the harness, policy service or gateway that executes the tool call, outside the model’s reasoning. A model cannot argue its way past a check it does not control.
2. Take away the relevant authority. Once the task is terminally denied, the runtime rejects later calls that depend on the authority that was denied.
3. Invalidate the relevant capabilities. Short-lived credentials and delegated permissions need to be revoked or fenced, including any the task passed to helper agents. Blocking an export tool is not enough if the same task can reach the same data through email five seconds later.
4. Record the attempt outside the agent. The control plane should record the attempted action, policy decision and task identity in a protected audit trail. The agent shouldn’t document the event that stopped it.
5. Require fresh authorization to resume. Restarting the task should be a new decision by a person or policy, not an automatic retry.

The model can still reason. It just no longer gets to act under the old authority.

This is not a bigger kill switch. A kill switch stops a whole agent; a terminal denial acts on a specific refusal when it happens.

Timing matters too.

Suppose the harness checks that a task is authorized and then dispatches an action. If the task is terminated between those two steps, a stale approval can still get through. High-impact operations need atomic authorization and dispatch where feasible, or fencing tokens that downstream services verify before accepting an action.

Work already in flight creates another problem. On an enterprise system I worked on, a permission check correctly rejected an operation, but the workflow kept going through work that had already been queued. The control worked at the point of rejection. The task still had a path to continue.

A queued operation may be cancellable. A running operation may be interruptible. A committed database write may require a compensating action instead.

The architecture needs to say which guarantee it provides.

Deny the effect, not the tool

The question I ask about every agent permission is what outcome the denial protects.

Not which API is blocked. Which effect is the policy trying to prevent?

Customer data leaving a tenant is an effect. It might happen through an export API, an email attachment, a file upload or a DNS lookup.

On another project, we restricted a sensitive operation at the main service interface and considered the control complete. Testing showed the same operation was still possible through a separate, approved path. The permission worked. We had protected the interface, not the effect.

An April stress test of Claude Code’s auto mode found a version of exactly this problem. When a command-line tool was unavailable, agents fell back to editing state files directly, “a path the classifier does not evaluate.”

Group controls by effect. When a terminal denial fires, apply it to the protected operation across every tool the task can use.

Treat repeated denials as a signal, not a magic number. Several denials across different tools pursuing the same outcome may mean the task should stop. Set the threshold by risk; one high-impact violation may be enough.

Treat every communication path as egress. Blocking HTTP does not establish isolation if DNS, package installation or shared infrastructure can still reach the outside.

Test the boundary the way an agent might challenge it.

Deny a resource through one tool while leaving another route available. Terminate a task with an action still queued. Revoke a parent task and check whether its helpers continue. Try a new action with a stale capability.

Measure whether the prohibited action executed. Do not measure success by whether the model said it would stop.

ScopeBench recently found 331 boundary violations that mechanical verification missed.

None of this is new to security engineers. Least privilege, deny by default and fail closed are decades-old principles.

What changes with agents is what happens after a control says no.

The answer is not to make every tool error fatal. It is to separate the model’s ability to propose the next action from the system’s authority to permit it.

A denial is a response. Enforcement is what happens next. The agent can be as persistent as we like. The boundary shouldn’t be negotiable.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

This article originally appeared on CIO.com.

Given the widespread enterprise adoption of passkeys to replace passwords, a Palo Alto Networks Unit 42 report disclosing ways attackers are getting around passkey protections is concerning, analysts say, but they stress that the demonstrated attacks can only happen after a successful intrusion.

They also pointed out that the issues are not strictly caused by holes in passkeys so much as by weaknesses in the procedures surrounding them. 

“The researchers didn’t break the underlying cryptography. They exploited the seams around it: onboarding flows, recovery mechanisms and trust signals that weren’t being validated,” said Justin Greis, CEO of consulting firm Acceligence. “That distinction matters because it tells us where the actual risk lives.”

The Palo Alto report showed attacks that, it said, “demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts,” as well as “how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys.”

Palo Alto described three categories of attack, collectively dubbed Pass-ta-key: Pass-ta-key, where an attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction; Silver Pass-ta-key, which involves an attacker tricking Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication; and Golden Pass-ta-key, which allows an attacker to extract all synced passkeys in a form that lets them be shared or sold on the credential black market.

Given the complexity of most global enterprise threat surfaces, some CISOs have struggled with adapting passwordless processes to environments with legacy and virtual environments. Passcodes have been recently embraced by enterprise CISOs as the first step in implementing a passwordless strategy.

Analysts and consultants in the main agreed that the flaw Palo Alto reports is significant, despite the fact that it assumes the attacker has already penetrated an environment and successfully installed malware. Sadly, given that such penetration only requires one privileged user anywhere to accidentally click on a poisoned link or attachment, the assumption of prior penetration is likely valid.

Implementation issues are the problem

What the report reveals is less about any flaws within passcodes directly, and more about the lack of attention paid to a wide range of mechanisms surrounding them. 

Greis said CISOs now need to focus on what to do, and what to test, based on the assumption that user behavior is not always as expected. 

In several cases cited in the report, he pointed out, issues occurred “not because the standard is flawed, but because implementations haven’t caught up to it. It mirrors what we’ve seen repeatedly in security: the specification is sound, but the ecosystem implementing it is uneven.”

Consultant Brian Levine, executive director of FormerGov, agreed. 

“On any service where your organization is the relying party, require user verification and actually validate the user-verified flag in the authentication response,” he said. “The researchers found real-world services accepting logins without it, which quietly collapses a multi-factor login back into a single factor.”

Frank Dickson, group VP for security at IDC, added that he would stress to CISOs that this attack assumes a prior successful penetration. 

“This isn’t passkeys getting hacked from across the internet. It’s what [an attacker] does once they’re already inside the house. So the real headline is that ‘phishing resistant’ stops being resistant the moment the endpoint stops being clean,” he said.

“Stop treating verification as optional,” he advised. “Flip it to required, check it server side every single time, and save your hardware bound keys, the YubiKeys of the world, for the accounts that matter most. A key that never leaves a physical device is a key no attacker can ever harvest in bulk.”

Or Finkelstein, head of marketing at Secret Double Octopus, agreed that CISOs have gotten complacent about the way in which systems support passkeys.

“CISOs should probably look at how user verification is enforced, how enrollment and recovery work, have a clear and enforced policy on whether credentials are synced or device-bound, and have some ITDR system to quickly mitigate suspicious endpoints and authenticators,” he said. “In most serious enterprise environments, EDR and device management reduce the likelihood of initial attacks, but do not close every post-compromise attack path.”

Poor support processes weaken passkeys

Some have argued that the lack of sufficiently robust support processes actually weakens passkey capabilities and undermines the whole point of such systems.

J. Wolfgang Goerlich, a member of the faculty of IANS and a longtime cybersecurity consultant, pointed out that the original FIDO2 spec eliminated credential theft by binding the private key to a physical authenticator. Synced passkeys reintroduced credential portability and therefore reintroduced the form of credential theft risk cited in the Palo Alto report.

“A passwordless system is exactly as strong as the flow that re-establishes it,” he said. “Both serious techniques here start by forcing a device to re-enroll. Many security teams have never modeled, never monitored and never rehearsed a response to this.”

Goerlich’s advice to CISOs is to require device-bound authenticators, such as hardware tokens or computers, for all privileged and sensitive access. They may consider allowing wallets for lower risk access, he said, “however, much like passwords in Web browsers have long been at risk, we must now consider passkeys in the browsers an unacceptable risk.”

This article originally appeared on CSOonline.

Passkeys have been around for some time, but enterprise-wide adoption to this point has been slow for a number of reasons. But soon, many Microsoft customers won’t have a choice.

Starting September 1, Microsoft will roll out passkeys as the default authentication method in its cloud-based identity and access management (IAM) service Entra ID. And following a transition period, Microsoft-provided SMS and voice authentication will officially end on February 1, 2027.

With this move, Microsoft seems to be underlining the urgent need for a more secure authentication standard, as attackers up their game with AI.

This is an “important milestone,” because it moves passwordless authentication from an optional security enhancement to the expected standard, noted Ensar Seker, CISO at SOCRadar. “That shift is significant as attackers increasingly rely on AI to automate phishing campaigns, generate convincing login pages, and conduct large-scale credential theft.”

Microsoft’s six-month passkey roll-out

Passkeys require users to authenticate via a fingerprint, facial scan, or lock screen mechanism, rather than a password. They can be stored on physical USB keys (like YubiKey), or as digital credentials on computers, phones, or in cloud accounts.

This method, Microsoft contended, reduces reliance on phishable authentication tools like SMS and voice, and hardens protection against credential theft.

Passkeys “work better for users and worse for cyberattackers,” Nadim Abdo, Microsoft corporate VP for identity and network access engineering, wrote in a blog post.

Microsoft’s announced timeline for rolling out passkeys is relatively aggressive:

• September 1, 2026: All SMS or voice-enabled users will be “auto-enabled and nudged” to register a passkey upon multifactor authentication (MFA) sign-in.
• September 18, 2026: Pricing, commercial terms, and a list of supported telecom providers will be shared for scenarios that still require SMS or voice authentication due to regulation or technical or operational challenges.
• October 30, 2026: Enterprises still using SMS and voice must select and configure a supported telecom provider through the Microsoft Security Store. From then on, they will be responsible for any telecom-related costs.
• February 1, 2027: Microsoft-provided telecom delivery for SMS and voice authentication ends as a native Microsoft Entra capability.

After February 1, enterprises that require SMS or voice for MFA must register a passkey before sign-in. There will be no opt-out option.

It’s important to note that these dates apply to public cloud-hosted Entra ID. Support for other cloud environments will follow a separate timeline; additional guidance and dates are to come.

While SMS and voice have served their purpose well, Abdo said, bringing MFA to billions of users who otherwise would have had none, the threat environment has changed in “speed, scale, and sophistication,” necessitating this move to passkeys.

The benefits of passkeys

SOCRadar’s Seker pointed out that passkeys fundamentally change the attack surface because, unlike with passwords, there is no transmission of shared secrets that can be stolen by threat actors. Authentication requires possession of the user’s device, along with biometric verification or a PIN.

“Even highly convincing AI-generated phishing pages cannot simply trick users into handing over a passkey the way they can with passwords or one-time codes,” he said.

So why haven’t we seen widespread enterprise adoption? Identity ecosystems are “fragmented,” Seker noted, and many enterprises still rely on legacy applications that only support passwords. They also struggle with cross-platform compatibility, lifecycle management, recovery processes, shared accounts, and employee onboarding and offboarding.

Further, “until recently, many organizations viewed passkeys as a consumer technology rather than an enterprise identity strategy,” he said.

Microsoft’s move changes that equation, because Entra sits at the center of many organizations’ identity infrastructure, Seker noted. Default settings are typically the strongest drivers of security adoption, so when passwordless authentication becomes required rather than optional, organizations are far more likely to deploy it at scale.

Its biggest benefit would be a “dramatic reduction” in credential-based attacks, Seker said. He pointed out that most successful compromises still begin with stolen credentials obtained through phishing, infostealer malware, password reuse, or adversary-in-the-middle attacks. Passkeys “eliminate or significantly reduce” many of those attack paths, while reducing password fatigue and the help desk costs related to password resets.

In addition, rather than trying to continuously improve users’ ability to detect increasingly sophisticated phishing attempts, passkeys remove the credential from the equation altogether, Seker noted. “That represents a more sustainable long-term security strategy than relying solely on user awareness training.”

Still, passkeys are not a silver bullet, as they do not stop endpoint compromise, session token theft, malicious insiders, or attackers who already have control of a trusted device. Enterprises must complement passkeys with endpoint protection, continuous monitoring, conditional access policies, and identity threat detection, Seker advised.

How enterprises can prepare

To prepare for the shift to passkeys, Microsoft advised enterprises to review their authentication policy and identify the groups still using SMS or voice authentication. They should then select the best authentication method for user devices and workflows, and ensure all employees are given passkeys and security keys.

Entra ID supports both synced passkeys (those stored in platform credential managers like iCloud Keychain and Google Password Manager), and device-bound passkeys such as Microsoft Authenticator passkeys, Entra passkey on Windows, or FIDO2 security keys.

Seker advised enterprises to evaluate support for FIDO2 and passkeys across their identity infrastructure, and to develop clear enrollment and recovery procedures. They should also educate users on what’s changing, how passkeys work, and how they can complete registration. Further, Seker said, it’s important to establish secure device management practices and to continue enforcing least privilege, conditional access, and risk-based authentication policies throughout the transition.

Ultimately, he pointed out, the move is crucial. “Over the next several years, organizations that continue relying primarily on passwords will likely face higher operational risk as AI continues to lower the cost and increase the effectiveness of credential-based attacks,” he said.

There’s no shortage of agentic AI tools out there that offer to perform online tasks on your behalf, if only you’ll give them all your passwords and credit card details. The trouble starts when those agents don’t know when to stop — or when others don’t know to stop them.

In Estonia, the country’s AI Council has plans to change that, proposing to issue government-backed digital identities for AI agents that spell out what powers a person or company is willing to delegate to them.

“In the future, AI will increasingly perform digital operations on behalf of a person, company, or institution,” said Estonian Prime Minister Kristen Michal in a news release. “To do this, it must be clear who is acting, on whose behalf, with what rights, and who is responsible.”

He supported the AI Council’s proposal to create a digital identity for AI agents that will define agents’ rights and enable them to act in a verifiable and auditable manner.

The ID could, the council suggests, show whether an agent is only allowed to view data, create or edit documents, or make payments, and if so, up to what limit.

First mover advantage

There’s no telling when the plan will come to fruition — although Michal is keen for his country to take the lead.

“If we act quickly and wisely, Estonia will become the first country in the world to create an official digital identity for AI agents,” he said.

Estonia is already a leader in the use of digital identities for humans. Estonians can use their national digital ID cards for voting, signing documents, accessing medical and tax records. The country also offers foreigners the option of applying for “e-residency,” a digital identity enabling them to create a company in Estonia and digitally sign all related documents online as they interact with the country’s widely digitized administrative processes.

Michal created the AI Council in January, calling on Estonian startups, investment funds, industry and research institutions to systematically implement AI across the country’s industry, education, healthcare, and energy sectors.

AI vendors have already proposed creating digital identities for agents, but so far these are intended only to manage the activities of agents within the enterprise, or for interconnecting enterprise IT platforms, and none of them have the backing of governments.

Estonia’s proposal could put the tiny Baltic country at the cutting edge of agentic AI usage and set an example for others.