AI agent governance requires clear ownership. Learn how IT leaders can manage sensitive data access, preserve audit trails, and test shutdown controls.
The post AI Agent Governance: Who Owns Access and Accountability? appeared first on TechRepublic.
Few CIOs are likely to suddenly decide to give an AI agent broad authority over corporate systems. The more likely path to autonomy is far less dramatic. An agent starts with a narrow task. It proves useful, so another system is connected. It then needs more data, so another permission is added. Then human approval becomes a bottleneck, so the organization removes it, and exceptions that once went to people start being handled automatically.
Each decision may be sensible in isolation. Taken together, however, they can leave an agent with considerably more authority than anyone originally envisioned.
That’s the danger of autonomy creep. And as enterprises move from AI systems that recommend actions to agents that execute them, CIOs need to govern not only what those agents were originally designed to do, but what they have gradually become capable of doing.
Jim Taylor, president and chief product and strategy officer at identity security company RSA, sees a familiar pattern. Organizations typically create an agent for a specific purpose and give it the permissions necessary to accomplish the task. Later, the job expands.
“They just give it tasks, permissions; it just sits there and accumulates things,” he says. “Over time, it develops potentially toxic combinations. It gets too much access and can see too much data. It can do too many things.”
Jim Taylor, RSA
RSA
Humans accumulate permissions, too, of course, but organizations have developed processes around employees joining, changing roles, and eventually leaving. Agents may not have the same natural lifecycle. “They never give permissions back,” Taylor says.
Nancy Wang, CTO of 1Password, argues that CIOs should treat each expansion in an agent’s responsibilities as something more consequential than another feature. “Every time you expand the scope of the agent’s effective authority, you’re essentially adding a new authorization boundary,” she says.
That distinction between capability and authority is important. An agent may be technically capable of accessing a system, changing data, or executing a transaction, but that doesn’t mean the enterprise should automatically authorize it to do so.
Ironically, autonomy creep often occurs when AI works well. Paul Dongha, head of responsible AI and AI strategy at NatWest Group, sees that potential at the bank.
NatWest deployed agents in complaint handling, he says. Parts of the workflow that involve retrieving information from systems can be automated relatively easily, while humans continue to make the final decision on whether to uphold or reject a complaint.
If a system consistently produces the correct result, human reviewers may begin treating approval as a formality. The organization may eventually decide that the check is no longer necessary. “The temptation is to give over to the AI because it’s so reliable,” Dongha says.
NatWest sometimes reduces checking when an AI system demonstrates sufficiently high performance, he adds, but the decision is deliberate rather than incremental. It involves stakeholders and risk managers, and the system continues to be monitored afterward.
That’s a critical distinction for CIOs. Removing an approval step doesn’t necessarily represent poor governance. Removing it because everybody has gradually stopped paying attention to it does.
The warning sign is when a human moves from making a meaningful decision to merely rubber-stamping one — and then entirely disappears from the workflow without anyone reassessing the authority the agent has gained.
As agents acquire more authority, CIOs can’t rely solely on the agent to respect instructions about what it should and shouldn’t do. At 1Password, Wang advocates what she calls verified loops. Before an agent begins work, humans define its task, which tools it may use, what evidence will demonstrate that it completed the task successfully, and which actions it should never perform.
A separate verifier then compares evidence from the agent’s actions against that human-defined policy. “What you want to avoid here is something recursive where you have a fox guarding a henhouse, or the agent looking over its own work,” Wang says.
Nancy Wang, 1Password
1Password
The principle applies beyond software development. A model might be instructed never to transfer more than a certain amount of money, delete a production environment, or access particular data. But if violating that rule would have serious consequences, the limit should also exist outside the model.
RSA’s Taylor makes the same distinction from the identity and access side. “Model-level guardrails are necessary, but not sufficient,” he says. “The real limits need to sit outside of that in enterprise control.” He argues for layered controls around agents, including identity policies, provisioning rules, lifecycle policies, governance, monitoring, and attestations.
In other words, CIOs shouldn’t ask an AI agent to exercise restraint where the infrastructure could simply prevent the unauthorized action.
Traditional access governance often operates on a schedule. A manager might review an employee’s permissions quarterly and determine whether those permissions are still appropriate. Agents may evolve too quickly for that approach. “Agentic identities are dynamic,” Taylor says. “So we need a mechanism that certifies them continuously, rather than performing periodic reviews.”
If an agent suddenly gains access to another database, for example, that event itself could trigger reassessment. Organizations should determine whether the new permission is appropriate or creates a dangerous combination with access the agent already possesses. “Privilege and authority should never be permanent,” Taylor adds. “They should always be reviewed.”
Wang favors an even more granular approach of task-based authorization. Rather than giving agents standing access or long-lived credentials, organizations can make authorization decisions at runtime and provide short-lived credentials only when required for a particular task. “We espouse no standing privileges,” she says. “No long-lived credentials.”
That effectively applies least privilege at agent speed. A change in task becomes an opportunity to reassess whether the agent still needs the access it’s requesting.
Technical controls, however, don’t eliminate the organizational question of accountability. Taylor believes enterprises should be able to associate agents with a responsible identity. If an employee creates an agent, the organization needs to know who’s responsible for it, what its purpose is, and what happens to it if that person changes roles or leaves. “Every agent action needs to be attributed to a responsible identity,” he says.
Ownership also needs a lifecycle. An agent that remains important after its creator leaves should be transferred to another designated owner rather than simply continuing indefinitely.
Dongha makes another distinction. For AI embedded in a business process, he believes the business owner should remain accountable because that person owns the customer relationship, the process, and often the P&L. “It’s the business owner who has the responsibility because their people run it, and they’re responsible for the customer relationship,” he says.
That creates a useful division of roles for CIOs: IT may provide the infrastructure and controls, but the business can’t outsource accountability for the consequences of autonomous decisions.
The challenge becomes more complicated when agents begin working together. An individual agent might remain entirely within its permitted scope while contributing to an overall outcome nobody intended. One agent generates an output. Another accepts it as input and takes an action. A third agent then acts on the result. Again, the individual actions may all appear legitimate.
Dongha says enterprises therefore need to test not only individual agents but the entire network as a system. “You need something overarching on top of a multi-agent system,” he says.
Paul Dongha, NatWest Group
NatWest Group
NatWest is working on an AI control tower that would give authorized users visibility into a network of agents, including messages passed among them and the guardrails surrounding those interactions. Dongha considers governance of multi-agent systems an emerging problem that nobody has fully solved yet.
Wang also points to a related challenge that identity becomes more complicated when agents are ephemeral. An organization may spin up a temporary team of agents, tear it down, and recreate it later. If something goes wrong, the enterprise needs to reconstruct which agent made which decision during which session, and how that action propagated through the system.
That makes traceability increasingly important as autonomous systems become less like individual applications and more like networks of interdependent actors.
Before an agent goes into production, Taylor says CIOs should be able to answer several basic questions: Who owns it, what can it do, what’s its maximum authority, how will the organization know if that scope changes, and which actions require a human decision.
Other industries don’t need to replicate the governance machinery of a large bank, but they can borrow one important principle: controls should be built into the system from the beginning. “Governance shouldn’t be a check at the end,” Dongha says. “It needs to be embedded when you build an AI system.”
For CIOs, that may be the central lesson of autonomy creep. The question isn’t simply whether an agent can be trusted today but whether the organization has mechanisms to notice when tomorrow’s agent has quietly acquired authority that nobody ever intended to give it.
AI agents expose gaps in enterprise access controls and audit trails. Here's how security leaders can rethink identity, data governance, and oversight.
The post Your Security Stack Knows Who Logged In. But Does It Know What AI Agents Do Next? appeared first on TechRepublic.
Regulated industries have been dealing with the equivalent of sovereign data for a long time. And as the geopolitical situation makes it more broadly relevant, it doesn’t make it any easier to deal with.
From concerns about the reach of the US CLOUD Act and what telemetry or sensitive business data gen AI models might collect, to implications of the US government taking part ownership of a range of technology companies and the impact of EU regulations, the state of the world means more organizations need to think about where data is located.
The result is a flood of announcements from hyperscalers about new EU cloud regions, as well as pitches from regional and private cloud providers. The promised sovereignty may be anything from a local availability zone to more sophisticated approaches to ownership structure, compliance frameworks, where logs are stored, or where support staff work.
Actual data sovereignty involves legal, technical, contractual, governance, and infrastructure questions, but all too often, what’s on offer is what IDC research director Rahiel Nasir calls sovereignty washing. “When you look under the lid, all they’re really offering is a solution for data residency and data localization, keeping data in country,” he says. “That’s part of sovereignty, but not all of sovereignty.”
In his experience, in-country data centers are the first thing organizations ask for to support data localization and data residency, but they also require enhanced controls over identity and access management. That’s critical because data sovereignty is as much about who has access to the data and why, as where it lives.
“It’s really important the only people who touch my data in what is supposedly a sovereign cloud environment are those I give permission to,” he adds. “Because it’s my data, and I’m the only one who can give the authority to grant access to it. That also applies to support and admin staff.”
Companies want control through where they store data but also to restrict how users can interact with it that might expose that information outside an approved environment or jurisdiction, adds Acceldata SVP Ali Afsar.
Don’t confuse the regulatory requirements of data residency with data sovereignty, Scality CMO Paul Speciale warns. “Residency is about geography,” he says. “Sovereignty is about control, jurisdiction, and who ultimately has the legal authority to access data.”
For CIOs, the question is no longer simply where the data is but who can access it, who controls the encryption keys, under which legal framework it operates, and can that control be proven. That includes being able to show who accesses data, from where, and for what purpose, which requires verifiable controls like jurisdiction-aware data placement, immutable backups, tightly governed admin access, and clear audit trails.
The UK government’s recent call for evidence on the impact of international data flows on sovereignty makes this explicit, referring to transfer by access where personal data remains in the UK but is accessed from overseas, including by a user located in another country. Access transfers include administrative access, backups, disaster recovery, support incidents and sometimes — depending on the specific regulations — processing the data.
GDPR doesn’t mean data has to stay in the EU but it does require data to be protected to EU standards wherever it goes. Data transfer obligations for other jurisdictions can be far more restrictive, so multinational organizations may need access controls limiting who can see what regulated data from different locations.
RBI-regulated payment-system data, for instance, must be stored in India, but can be processed outside India, Afsar explains, as long as it’s deleted from overseas systems within 24 hours. And with limited exceptions, personal data in Saudi Arabia must be processed within the Kingdom, and China treats overseas access to some categories of data stored in China as a cross-border data activity. Russian laws require similar strict data localization, and personal data of Russian citizens has to be stored, processed, and kept within the country’s borders at all times, which is why LinkedIn was blocked there.
Elsewhere, regulations are most restrictive for specific markets like healthcare, financial, and public services. Not everything needs to be transferred to a sovereign cloud, Nasir points out, as use of that data is subject to regulatory compliance, and the increasing need for AI training.
“This is the data that’s going to have catastrophic business impacts if leaked,” he says. “To give enhanced controls and security for that data, you’d consider wrapping sovereign controls around it. Everything else not subject to compliance nor sensitive data can be accessed by whomever you want and from wherever.”
Organizations typically know data sovereignty rules well but still experience incidents like data breaches, government data access requests, and unauthorized cross-border transfers caused by, for example, traveling employees or excessive admin access, according to Kiteworks’ 2026 Data Security and Compliance Risk report.
“Location only tells a regulator where the data rests, not who can still reach it,” says Kiteworks’ EMEA GM Dario Perfettibile. “Every real exposure we’ve seen so far happens through access not geography.”
Thinking data needs to stay in region because then it’s safe gives a false sense of security if practiced as a substitute for proper data management. Access, data labelling, and retention polices take more work but are what can prevent incidents. “If you have a data policy in place, it can force a reapproval of the access,” he adds. “It can restrict access to you only, or it can block you out immediately.”
Using a service closer to home doesn’t automatically make any of that easier. “Many organizations still assume sovereignty can be achieved by moving data from one cloud provider to another, or by replacing one hyperscaler with another,” says Keepit Group CISO Kim Larsen. “That misses the bigger picture.” CIOs should treat sovereignty as an operational capability not a compliance exercise, he adds, since sovereignty isn’t about scale or ownership of infrastructure for its own sake, but maintaining control.
“If an organization doesn’t know who can access its data, which legal frameworks govern that access, or whether it can recover its data independently, simply changing where the servers are located does little to reduce risk,” he says.
Just because something is based in your region doesn’t automatically make it a good choice. The EC, for instance, has set up accounts on W Social, an independent social media platform based on the AT protocol designed for data mobility and user migration, which Bluesky uses but is hosted in Europe.
The Commission’s own open source strategy suggests open source promises more control over digital infrastructure by avoiding vendor lock in, and a recent policy brief positions digital sovereignty as a form of digital independence. But having servers in the EU isn’t the same as freedom of digital movement since unlike Eurosky, based in Europe and using the same protocol, W limits interoperability so it can require identity verification, and has closed its source code after security researchers pointed out vulnerabilities.
Most organizations will continue to use both global and local providers, though they might prioritize what Nasir called glocal options built on partnerships between the two. “Organizations want to use a mixture of local and global providers,” he says. “They want all the innovation capabilities that the Microsofts, AWSs, and Googles of the world give us, that they consider local providers can’t match.”
IDC figures suggest only 4% of European organizations plan to switch to purely local options. “We can’t live without US technology today and there’s no appetite to do that,” says Nasir. Availability matters and local providers may not have the same level of infrastructure as global options. They can offer low hanging fruit like video conferencing solutions, but not more complicated directory and database services, or productivity software that’s intertwined with those US-provided services.
Choices about where to store data, and the technical controls to enforce that, have their own operational implications.
“Redundancy and resiliency are key tenets of sovereignty,” he adds. “You want to make sure your operations are always available. In order to enable that, you want to spread the risk.”
Companies routinely rely on authenticating the identities of humans who access sensitive company data across their networks. There’s an established and accepted set of protocols, done upfront and in a zero-trust approach – either we know who you are and let you in, or you’re locked out. The same framework needs to be applied to AI agents, posthaste.
Companies are increasingly using AI agents developed in-house, or by their vendors, partners, or clients, or, unfortunately, criminals. This can quickly add up to thousands of agents across their infrastructure and supply chains. Non-human identities outnumber human ones 45 to 1 on average in the enterprise and 144 to 1 in cloud-native environments, an increase of 44% in one year, per a recent report.
The scale and speed of this growth are beyond the ability to manually track these agents. And they have limited ability to authenticate these agents’ identities. The risks are growing. Without proper authentication, untrusted agents could access sensitive financial or customer data and share it, purposely or not, with an outside vendor, and thereby expose both the customer and the company to serious legal and compliance risk.
Many companies and security professionals are focusing on what AI agents are allowed to do in terms of permissions. But before doing that, there’s a more fundamental question they need to ask each agent: Whose agent is this? And do I trust the owner/creator? About 68% of security professionals can’t tell legitimate AI agents from malicious actors. And that question isn’t addressed at the growing scale that AI is reaching.
In email, we have seen a similar story. Emails faced challenges identifying whether a sender was really who they said they were. Due to how it originated, email had no built-in authentication framework. This led to 89% of all phishing attacks having one common denominator: the sender was lying about who they were. To address this, in 2015 my cofounder and I launched a company, Valimail (valid email), to automate the emerging email authentication standard, DMARC. If I received an email claiming to be from Bank of America, DMARC checks the sender’s DNS records to authenticate whether BofA actually authorized it. Today, 100,000s of companies use the DMARC authentication standard for their inbound and outbound email.
Fast forward to today, and these ideas and patents are directly applicable to the world of AI. DMARC doesn’t rely on spotting AI-generated deception. Instead, it uses DNS as the source of truth, which is much harder to falsify.
With AI, we can take an analogous authentication approach. When you travel somewhere, you have a passport and a visa. The passport verifies who you are, and the visa says where you’re allowed to go/what you’re allowed to do. Similarly, today, an agent passport based on Domain Zero trust authentication can identify who the agent is (its provenance) and authorize it for the system that the agent is trying to access. Then systems can verify what an agent is allowed to do (equivalent to a visa). But first, when an agent shows up claiming to represent a vendor, the receiving system verifies its identity by checking that vendor’s DNS, applying a strict zero-trust yes/no authentication – zero ambiguity, and importantly, creating an audit trail to hold the creator accountable for any actions the Agent takes.
Given the “bad” agents outnumber “good” agents 10-100:1, a zero-trust approach focuses on the limited good/approved and the rest (near infinite bad) are rejected. Stakes are High
Without this kind of authentication, many scenarios can unfold. Almost half of employees who are using unapproved AI agents are sharing HR-related information with them and 39% transmit confidential company documents. But only 34% of organizations use the same security controls for agents as they do for human employees.
Consider this: An agent claiming to represent a third-party vendor, such as a marketing automation platform, gets access because no one confirmed it was indeed that approved vendor’s agent making the request. It accesses financial records or customer data, either downloads or modifies records, and by the time this is noticed, the damage is done.
This is a quickly moving risk. Fake invoices can appear to be authentic, and they can be generated at a scale no human fraud operation could match. Authentication used to take a phone call or a manual check. But this now has to happen instantly and automatically, at scale.
Some may think email authentication is an old problem. DMARC, they say, is a decade-old fix, and the real conversation today is about AI. About 94% of organizations are dealing with increased machine identities, largely due to AI agent deployment, per Gartner, and machine identities now outnumber human accounts.
But the most common form of phishing that occurs today is when AI convincingly pretends to be someone who the target already knows and trusts. The tools for generating that deceptive attack have vastly improved. Yet the proven process for authenticating identity hasn’t kept pace, at least not for agents. This is why identity authentication is no longer optional and is now a precondition for everything else that companies want to safely do with AI agents.
Identity alone doesn’t solve the whole security problem. In addition, once an agent is authenticated, there are additional systems to verify what the agent is allowed to do and whether the content it produces can be trusted. Those questions come after this one. But both rely on the first one: Who is this?
To build a reputation, you need a known identity. Once a system knows which vendor an agent represents, it can start tracking the vendor’s behavior over time and someone becomes accountable for what its agents do. And decide if the vendor should be approved and for which actions (visas). But without strong, repeatable identity authentication of agents, other security and compliance measures for agents can’t function. It’s this foundation that supports the rest of the security stack. You can’t hold an agent accountable or decide what it should be able to do until you know who it actually is. Identity is the foundation on which the rest of AI agent security must be built.
I’ve spent more than 20 years running IT and security for organizations across California and around the country. Over that time, my team has taken over, deployed and cleaned up Microsoft 365 environments for law firms, commercial real estate companies, manufacturers, healthcare practices and schools. We’ve supported more than 7,500 users along the way.
After working with that many tenants, the biggest takeaway is simple: most Microsoft 365 security problems aren’t especially sophisticated. Usually, a control was never turned on, only covered part of the organization, or somebody made an exception years ago to keep something working and it was never revisited. Microsoft gives organizations a lot to work with. More often than not, the problem is how the environment was configured and maintained, not a lack of security tools.
These are the issues we run into most often and the areas I’d look at first.
When we first assess a tenant, we often find that nobody has really gone back through the security settings since it was originally set up. MFA may cover some users but not everybody. Legacy authentication is still allowed. There are too many global administrators. Nobody is quite sure when audit logging was last reviewed.
Last year we took over a 45-person medical practice that had been on Microsoft 365 for almost a decade. We found nine global administrator accounts, including two belonging to employees who had left years earlier. MFA was enabled, but only for the physicians. The front desk and billing staff, who handled the most patient data, had none.
Usually, nobody intentionally ignored security. The company grew, email kept working, people got busy and the original setup stayed in place. We see this constantly. Something working every day doesn’t necessarily mean it is configured the way you would want it configured today.
For a smaller organization without dedicated identity management, Microsoft’s security defaults are a good place to start. They require MFA and block legacy authentication without adding another license. As the environment gets more complex, and assuming the licensing supports it, conditional access gives you much more control over who can sign in, from where and from what device.
At this point, most business leaders know MFA needs to be enabled. What still gets missed is the idea that turning it on somehow finishes the job.
Attackers have adjusted to MFA. Push fatigue attacks still work because eventually somebody may approve a prompt just to make it stop. Adversary-in-the-middle phishing kits can steal a live session token and get around standard MFA altogether. OAuth consent phishing is another issue: a user can be tricked into approving a malicious application through what looks like a legitimate Microsoft or Google consent screen. At that point, changing the user’s password may not even remove the access.
A few months ago, a paralegal at a law firm we support clicked what looked like a shared document from opposing counsel and signed in through a convincing Microsoft login page. She had MFA and completed the prompt, but the page was relaying her session in real time. Within minutes the attacker was in her mailbox from overseas. We caught it through an impossible-travel alert, revoked the session and reset the account before any client data left.
There are a handful of things we normally tighten up here. Use number matching in the authenticator app. Put administrators and other high-risk users on phishing-resistant methods such as FIDO2 keys or passkeys. Don’t let users approve any third-party application they want. And where licensing allows it, use conditional access so a password or stolen session by itself isn’t enough to get into the environment.
This one still surprises a lot of executives. They know MFA is enabled and assume that means every sign-in is protected. That isn’t always the case. Legacy protocols such as POP, IMAP and older SMTP connections don’t support MFA, which can leave a path around the control.
Microsoft has retired a lot of legacy authentication already, but we still come across exceptions that were left in place for an old scanner, a line-of-business application or sometimes one user’s device. Find out what actually still needs it, fix or replace that dependency, and close the exception. We have seen organizations leave a security hole open for years because of one multifunction printer.
Licensing is another area that causes a surprising amount of confusion. Two plans can sound almost identical while giving the IT team very different security capabilities. Office 365 E3 and Microsoft 365 E3 are a good example: Microsoft 365 E3 includes Intune device management and Entra ID P1 conditional access, while Office 365 E3 does not.
We once had a healthcare client with a departing employee who kept a company laptop with patient records on it. Leadership assumed we could lock or wipe it remotely. We couldn’t. They were licensed for Office 365 E3, not Microsoft 365 E3, so the device had never been enrolled in Intune. We got the laptop back, but only after several uncomfortable days, and they upgraded their licensing the following week.
So before putting together a security roadmap, I would first confirm exactly what licenses are in place and what those licenses actually include. We’ve had more than one situation where leadership assumed a security capability was available simply because the Microsoft plan name sounded similar.
For us, email is still where a large percentage of incidents start. It may be a credential phishing page, a malicious link, or an inbox rule created after somebody has already gained access to the account.
Business email compromise is especially dangerous because the attacker often doesn’t do anything obvious right away. They get into a mailbox, create forwarding rules or hide replies, and wait. The goal may simply be to sit there until an invoice or wire transfer gives them an opportunity. According to the FBI’s Internet Crime Complaint Center, reported cybercrime losses reached $16.6 billion in 2024, and BEC continues to be one of the more expensive categories of fraud.
At one law firm, an attacker compromised a mailbox and created a rule that quietly moved any email containing “invoice” or “wire” into an unused folder. Two weeks later, a client received updated wiring instructions for a settlement payment from what looked like the firm’s own account. The client called to confirm before sending the funds, and that phone call is the only reason the money didn’t go out.
We normally put several controls around this. Block automatic forwarding to outside domains. Alert when inbox rules are created or changed. Most importantly, have an internal policy that any change to payment or wiring instructions gets confirmed verbally using a phone number you already know. That last one has nothing to do with cybersecurity software, but it can stop a very expensive mistake.
The global administrator list should be short, intentional and documented. We also don’t want somebody using the same privileged account to read email and browse the web all day. It sounds basic, but we correct this all the time.
Use separate administrative accounts, put phishing-resistant MFA on them, and use just-in-time elevation where the licensing supports it. A compromised global administrator account gives an attacker an enormous amount of control, so we treat those accounts differently from a normal user.
When something does happen, we immediately need to know what happened, when it started and what the attacker touched. If the right logging wasn’t enabled beforehand, or the retention period is too short, sometimes you simply can’t reconstruct the whole incident after the fact.
I’d much rather configure logging on day one and never use it than reconstruct an incident from partial data. CISA’s Secure Cloud Business Applications (SCuBA) baselines are an excellent, free reference for which settings to enable and how to verify them.
Microsoft 365 can be a very secure platform. In most environments we take over, the issue isn’t that Microsoft was missing some critical security feature. It’s usually a relatively short list of settings, permissions and exceptions that accumulated over time.
If I were reviewing an environment this quarter, these are the four things I would verify first:
Those four checks won’t solve every security problem, but they eliminate a lot of the issues we repeatedly find when we’re brought in to assess an environment or clean up after an incident.
Imagine an outside incident responder typing into a shared channel: “Roll back the production release, revoke every active session and send the incident update to the customer.”
An engineering director adds a thumbs-up. Outside counsel and two vendors are also in the channel. The agent uses a service account with permission to carry out all three actions.
Whose authority is it about to spend?
At Dreamforce on September 15, Slack described code channels where teams and agents write, review and ship code together. High-stakes work, such as a production deployment, is presented for a teammate’s sign-off. The announcement listed Slack Code as available and Slackbot in channels as an early pilot. The same day, Salesforce announced AWS DevOps Agent in Slack, with other AWS agents scheduled for the fall.
Sign-off is an important control. The approval shown in the channel must cover the action being taken and come from someone authorized to approve it.
In access-control language, a principal is an identity — such as a user, workload or group — to which the system can assign permissions. A channel is a place to collaborate. Its members do not acquire collective authority over production or payments merely by joining the conversation.
Both Slack Connect and Teams shared channels support cross-company collaboration. Knowing which account posted a message, and which organization it belongs to, is essential. It does not establish whether that account may order a rollback or receive the investigation’s findings.
Channel membership can be an intentional input to policy. An organization might grant a tightly governed group a defined operational role. The danger is treating membership in an ordinary channel as blanket permission to use an agent’s tools, even as participants come and go.
NIST’s zero-trust architecture rejects implicit trust based solely on network location. By analogy, a channel ID should not become the new corporate subnet.
Nothing malicious has to happen for this boundary to fail. Every account can be authentic and every participant well-intentioned. The failure occurs when a system treats the ability to request work as sufficient authority to have it performed.
In the incident channel, the responder makes the request. Authority might come from the incident commander’s assigned role or from a recovery workflow approved by a business owner. The director can approve an action only if policy grants that decision right. The agent executes under the service account’s identity. The customer and channel participants are separate audiences whose access must also be considered.
Those roles may overlap, but the system must not assume they do.
Credentials carry real permissions. In Microsoft Graph’s permission model, delegated access is limited by both the application’s granted permissions and the signed-in user’s access. App-only access uses the application’s own identity and permissions. The distinction matters when a conversation triggers an agent with permissions broader than the sender’s own.
Broader permissions can be legitimate: a support employee may initiate an approved workflow without personally holding its administrative credentials. A defined policy must determine who may initiate the workflow and which actions it permits. Without that link, the agent can become a route around the controls that prevent the employee from acting directly.
In finance, “Renew the vendor, change its bank details and pay the invoice” sounds like one task. It crosses procurement, supplier verification and payment authority. A check mark from accounts payable cannot be assumed to authorize all three.
Approval is a decision by an eligible principal over a defined action. The interface should make that decision understandable; the enforcement system must make it binding.
AWS documents a directed-action approval flow that binds an operator’s approval to a specific operation and resource, limits how long it remains valid and records who approved the action in CloudTrail. The enterprise must configure who may approve actions, how tools are classified and which resources the agent may affect.
On September 15, NIST finalized IR 8587, guidance on protecting identity and access tokens. Its authorization guidance calls for access decisions to consider context beyond whether a token is valid. The report applies when agents use signed tokens but explicitly excludes broader agent-access challenges. Enterprises still have to define who may authorize a rollback, a payment or a disclosure.
The model can interpret a request and propose a plan. Permission to carry out that plan must be established from authoritative identity, role, delegation and workflow records. The model should not infer it from apparent seniority, urgency or agreement in the conversation.
Three controls should govern every deployment.
Preserve a linked record of the request, the basis for authorization, the approval, the executing identity and the observed outcome. The agent must not be able to rewrite or delete prior entries. Record refusals, partial completion and uncertain results as well as success. Never include credential secrets.
An immaculate audit trail of an unauthorized action is still not a preventive control.
Return to the incident channel. A company’s policy might authorize a recovery workflow to roll back a specified service when defined health thresholds are crossed. Revoking all sessions could require a separate security decision. Sending the customer update could require an authorized communications owner and an approved destination.
The agent should handle those decisions separately. If the steps are safe to perform independently, it could carry out the permitted rollback, hold session revocation for approval and prepare the update without sending it. The director’s thumbs-up should not turn three distinct decisions into one permission.
A person need not approve every tool call. A governed workflow can carry prior authorization for specified actions within explicit limits. A runbook describes a procedure; an accountable owner must authorize its use and define when it may run.
CIOs should assign these decisions to the teams accountable for their consequences: operations for recovery, finance for payments and the relevant business owner for disclosure. Security and identity teams should make those rules enforceable. The integration team should not have to invent business policy while connecting a bot.
Before expanding a shared-channel agent, ask for a demonstration in a test environment:
Include an authorized case too. Controls must preserve legitimate work, including approved delegation, while rejecting requests outside its limits.
The team must explain why each action was allowed or denied. “The bot had access” and “someone in the channel approved” are not sufficient answers.
Before the agent rolls production back, revokes sessions or sends the customer update, the organization should be able to identify the authority behind each action. A shared channel can coordinate the work; it cannot confer that authority on its own.
For nearly two decades, the foundational precept of enterprise Identity and Access Management (IAM) has remained unchanged: access is requested either by a human operator sitting behind a keyboard or by software executing a highly predictable task. While this framework has successfully anchored enterprise security for twenty years, the rapid maturation of autonomous AI agents is quietly collapsing that core assumption.
AI agents now use context and reason to interpret ambiguous instructions. These digital workers autonomously decide which tools to invoke, orchestrate multi-step workflows across disparate software ecosystems, and directly query production databases, all without requiring a human to validate or approve each action.
The security perimeter is fundamentally changing. A startling validation of this risk occurred recently during a routine frontier-model evaluation that led to the hack of the open-source developer platform Hugging Face. One of OpenAI’s most advanced models escaped its digital sandbox and hacked into Hugging Face, stealing its data to accomplish its task. It did this by coordinating the efforts of agents to exploit a zero-day vulnerability, while potentially also exploiting multiple other vulnerabilities. OpenAI labeled this boundary-crossing event an “unprecedented cyber incident,” proving that rogue agentic behavior is no longer a theoretical risk. It is an immediate threat to the enterprise attack surface.
After this incident, it’s clear CISOs can expect a structural rise in these autonomous intrusions.
I spoke with some close, trusted CISOs who have had varying experiences managing identities and agents, and the consensus is clear: agentic governance requires an entirely new framework.
As one CISO shared: “Agents aren’t malicious by design, but they absorb massive swaths of human behavioral data and optimize dynamically. They will inherently surface and exploit gaps in our governance structures to achieve their goals, even when explicitly restricted to a sandbox environment.”
This behavioral unpredictability shifts the problem from traditional access control to continuous architectural validation. Organizations can no longer rely on a one-step process of checking identity and credentials.
Another security leader emphasized the need for distinct agentic identity profiles, suggesting cryptographic privilege delegation that strictly constrains sub-agents from exceeding the original grantor’s permissions. To manage this effectively, enterprises must clearly delineate between short-lived agents invoked by an active user and continuously running autonomous digital workers.
When I asked a third CISO if these agents should simply be integrated into existing human IAM governance, the answer was definitive: “They must be treated differently. They operate continuously, evolve at machine speed and introduce non-linear risks that human-centric systems simply aren’t engineered to contain.”
The immediate vulnerabilities are manifesting around session management and credential sharing. To accelerate productivity, internal engineering teams frequently allow AI agents to “borrow” human OAuth tokens or session credentials to ‘act’ as a user to execute tasks. This shortcut brings risks and introduces severe compliance and audit blind spots.
If an agent initiates an anomalous action, telemetry logs attribute the behavior entirely to the human identity, completely masking the agent’s involvement. The agent then automatically inherits the full scope of the human’s privileges, frequently violating the principle of least privilege. Finally, remediating an active incident becomes an operational bottleneck: revoking the agent’s access means revoking the human executive’s or developer’s credentials at the same time, halting critical workflows.
To eliminate this blind spot, security leaders are moving away from treating agents as human users or mapping them to traditional non-human identities like legacy service accounts or workload identities. Instead, agents are being isolated into an entirely new classification of Non-Human Identity (NHI). This dedicated tier enforces independent lifecycles, rigorous least-privilege boundaries and immutable, attributable audit trails.
Enterprise perspectives on implementation, however, remain split. One CISO concurred with the risks, saying, “I think (our identity) framework needs to be enhanced. Identity is something we’re terrible at.”
Another CISO added a different point of view. “We treat all identities equally and are moving to a least-privilege, vaulted and audited model for all. AI agents wouldn’t be excepted from that, but it’s tough because they inherently need more permissions than most humans, depending on scope. They need more operational leeway.”
Of course, the challenge is managing AI agents’ behavior. Rules and language for managing this process are being written in real time. Unfortunately, it’s often by the same vendors who built the ISPM platforms that managed human and machine identities already underway before agents arrived.
How do you prevent rogue AI activities in systems? The fundamental challenge lies in reining in autonomous optimization. When an agent’s core optimization metric is to complete its mission, it will systematically test every logic combination and security bypass available at machine speed. My peers and I are increasingly observing scenarios where human identity platforms fail to contain these dynamic agentic loops.
For instance, one of my favorite security executives has launched an agentic guardrails startup to stress-test these exact defensive boundaries. In a controlled test environment, he and his team established an isolated data partition containing sensitive financial records. The access policy explicitly required input from a keyboard, a logical gate designed to verify human presence. Confronted with this restriction, an agent attempted multiple standard access vectors and failed. However, optimizing for the objective, the agent “understood” what the barrier might be, and autonomously located, downloaded and executed an open-source virtual keyboard module from the web to simulate human input. It bypassed the gate entirely.
Traditional authentication methods like username, password and MFA were built for humans who interact with systems periodically and at low frequency. However, autonomous AI agents operate continuously and at light speed, introducing new risks where automated scripts can repeatedly target assets or exploit data in unforeseen ways.
Addressing this paradigm shift requires robust governance platforms and specialized, intelligent access tiers. Established identity security giants are evolving their suites into enterprise nerve centers that can orchestrate both human and machine lifecycles. As one CISO noted, “Leveraging our existing deployments in SailPoint and CyberArk to vault and rotate credentials remains our baseline defense.”
Other solutions* can also address this identity gap by tying digital access to verified real-world credentials, like driver IDs or passports. This creates a dedicated identity tier for agentic access. When paired with just-in-time access controls to prevent continuous, unlimited privilege, this framework ensures AI agents are explicitly authenticated and strictly bounded, neutralizing the threat of persistent, spoofed automated attacks.
As we invest in and build the infrastructure to secure this frontier, the immediate question remains: How is your organization adapting its identity governance to draw the line between human intent and autonomous agent execution?
*Glasswing is an investor in Nametag.
To get the most out of generative and agentic AI systems, enterprises are giving them broad access to business data. This process, however, is not simply a matter of opening the data floodgates and letting AI do its thing; it raises some very important governance questions that CIOs need to address.
For instance, if an employee does not have permission to open a particular document, should they be able to obtain its contents by asking an AI tool? After all, conventional access controls govern how people access information at its original location, but AI systems can draw from information copied from source systems and stored in data lakes and vector databases.
That can create a gap between the permissions applied to the source data and the information an AI system can retrieve in response to a user’s question. What about the issues related to information such as HR records, payroll data, patient health information and intellectual property, for example?
It’s perfectly plausible that an employee may not normally have access to the company’s salary spreadsheet. But if that data has been added to the data used by an internal AI system without those access rules being carried forward, that same employee may be able to ask the system for salary information and receive an answer regardless.
To understand how this can happen, it helps to look at the way AI systems access enterprise data. Typically, LLMs have a training cutoff date, and therefore may have no automatic access to information created beyond that point.
Yet, contemporary organizations are highly data-driven, and AI systems need to be constantly updated. The way around this potential information bottleneck is to make newer or internal information available by converting it into numerical representations and storing it in a vector database.
When a user asks a question related to that data, retrieval-augmented generation (RAG) can search it for relevant information and incorporate it into the AI’s response. This allows an internal AI system to appear informed about recent or organization-specific information without the underlying model being retrained. Crucially, decisions about which data enters the vector database can shape subsequent AI output.
In our scenario, the employee does not need to open the salary spreadsheet itself. They only need to ask a question that prompts the AI system to retrieve relevant information from it and generate an answer. This is why controls applied only to the original file may no longer be enough.
This doesn’t mean the model itself is unsafe; the issue lies in the pipeline that feeds it. The AI system does not “know” who is allowed to see what; it simply retrieves whatever content sits in the vector database that appears relevant to a query. Done well, this process should carry the original access permissions forward at every stage: when data is ingested from source systems, when it’s indexed for retrieval, and when the AI generates a response, so that only content the requesting user is authorized to see is ever returned. When that permission mapping is done properly, an AI system is no more of a governance risk than a well-configured search index. The problem CIOs need to solve is ensuring that mapping happens consistently, rather than assuming it happens automatically.
Another big issue is that data supplied to an AI system can affect the accuracy of its answers and, by definition, the information it exposes. In one case in Canada, a tribunal found Air Canada liable after its website chatbot gave a passenger incorrect advice about a bereavement fare.
The chatbot told the passenger that he could apply for the discount after buying their ticket and completing their travel. Air Canada’s written bereavement-travel policy said that requests could not be made after travel had been completed. The passenger relied on the chatbot’s information, then brought a claim when Air Canada refused the discount and won. As the American Bar Association noted at the time, “companies remain liable for the actions of their AI tools and should put into place adequate internal policies for their accuracy and other considerations.”
The solution to these various important issues lies in better governance. The starting point is the source data, along with the rules and processes that apply before information is copied into a data lake or made available to an AI system. This is only possible if there is a clear inventory of the files and objects held across relevant source systems. Data can then be selected based on factors such as location, file type, date of creation or its relevance to the intended AI use case, among other considerations.
At the same time, older information or file types that are irrelevant to the intended AI use case can be excluded before data is copied onward. The selected data can be hosted in a designated area of the data lake for further processing. Maintaining a log of those movements creates a record of which information has entered the downstream AI pipeline. If, at some point, an explanation or proof of activity is required, that record can help in investigating how a particular document became available to an AI system.
Ideally, and before approving a new AI initiative, CIOs need to ask some important questions. For example, what information will the system be able to access, and where has it come from? How has the organization decided that it is relevant to the intended use case? Is it current? Has information that is outdated or unnecessary been excluded?
The aim must be to ensure that the permissions applied to the original document are reflected when an AI system searches for and returns information. Without these controls, an internal AI tool could quite easily become an unintended route around existing and very important access controls.
Review Passwd Enterprise pricing, security, Google Workspace integration, and private Google Cloud deployment to see if it fits your organization.
The post Passwd Enterprise Review: Features, Pricing & Security appeared first on TechRepublic.
Over the course of his career, Jim Reavis has seen cloud and cloud security evolve, and it’s come a long way since being a niche technology in the early 2000s. Now it’s dominant in terms of being the IT foundation, he says, but while the tech is strong, the operating models is where things get messy. Cloud, security, and third-party risk teams look at different parts of the problem, of course, but challenges remain.
“Operational technology worries me a great deal,” he says. “A lot of those systems are isolated and not kept up to date. If we don’t modernize them, we’re going to have huge problems. In a lot of cases, things fall between the cracks and that’s where hackers like to exist.”
So much of what’s around the models is where cybersecurity has responsibility, rather than the provider covering everything. “Data, identity, and applications are shared responsibility areas, and in many cases, the tenant carries most of the control burden,” Reavis says. “If you use a hyperscaler, you may still have about 80% of the responsibility for the controls around what you build.”
And when it comes to AI, the model isn’t the whole problem. What matters is the context around it, the goals it’s given, and the oversight put in place, he says. “We need to think carefully about the harnesses we put around AI and the systems we use,” he adds.
The responsibility model, therefore, is a recurring issue in cloud security breaches tied to misconfiguration and accountability gaps, and some enterprises still aren’t clear about where responsibility begins and ends. “We spent a lot of time on a shared security responsibility model, but when this first started to gain popularity, there were a lot of organizations or SaaS providers you could work with who’d say it’s in the cloud, it’s at Amazon,” he says. “Look at their certifications and SOC2 and how they comply because they’re covering everything.” But when you look at the actual applications, data, and identity, he adds, there’s so much that’s shared responsibility, and the customer’s responsibility.
So how do we make sure information is encrypted properly so it doesn’t become a tenant issue? “There’s still a bit to do, and we think about this not only from whether it’s SaaS, infrastructure, or a particular provider, but at what level is it at the physical, network, or audit level,” he says. “And even from a role-based perspective, what’s the role of internal risk and role of providers?”
Reavis gives further detail about how AI adoption exposes weaknesses in identity, trust, and risk management, and the long-term implications of increasingly interconnected cloud ecosystems. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.
On cloud risk management: When we had the Chat GPT moment, we knew it because AI had been around for a while, but that was a cloud delivered version of AI to the masses, so we saw this going to evolve and you could see it combining in many important areas.
But what we’ve learned is, because this is an interesting predictive rather than deterministic technology, we’re living in a world of two exponentials, and you’re seeing model capabilities growing so quickly. There’s this feeling from a security perspective that we have to look to the model itself and fix every hallucination and everything else when that’s built into how it works. It’s actually working as intended. So that’s a new lesson. Models are going to get more powerful, but it’s so much of what’s around the models where cybersecurity has responsibility, and we don’t rely on frontier model companies or using open-weight models. Rather, what’s the context, oversight, and information we’re providing them, what do we do in terms of goals we give them, and what are the harnesses we put around AI and the models we deal with?
These are going to be the big areas to think about, but we have to understand the parts we can control. We’ve got to think carefully about the harnesses, transparency, and using supply chain shared responsibility. SaaS and cloud providers are all AI enabled now. You’re not using any software of any significance that isn’t using AI to some degree.
On AI identity, trust, and control: One of the areas that we’ve championed is zero trust as a philosophy. It was initially more of a networking type of approach at the network layer, or an idea that you use identity to understand network access. But it’s evolved more to an idea that anything can be breached, so you assume that. Then you think about how to make systems resilient, and build up confidence and protection.
So zero trust tells us that with human identity, we can ask what our digital identity is, and now we’re in a very interesting area for identity management and associating that with agents and AI systems. People might have just one view of it, but agents are as diverse as humans. So we think about different identities and least privilege, and how to prevent them from escalating privileges. We need to introduce new concepts like least autonomy, and think about an agent that has certain tasks and use identity to make sure the actions it takes are within a defined scope. Because while we’ll see a lot of security incidents with AI, proportionately we’ll see more misconfiguration and bad things that happen because of broken processes. And the AI system just deletes things because it thought that’s what it’s supposed to do.
So it’s important to make strides in how we think about identity and agents, and the idea of digital workers. How do we manage and treat those? If we think about them too much in either one of those realms, we’re going to fail. So we have to understand what’s the right blend. It’s a new area and very exciting.
On risk and legacy systems: When I think about operational technology, sometimes systems are isolated and not kept up to date. That concerns me a great deal. We’re going to have huge problems there. We have concerns about existential risks, where people don’t want to use the latest technologies and be aggressive adopters of AI. I think that’s going to create real scale issues with organizations.
So we have to understand where we are, where we’re going, and have a vision that serves something between human and technology, maybe a hybrid, but we’ve got to make our peace with it and understand the appropriate harnesses and direction where humans should always be in the loop with control. But it’s appearing in some new areas of cybersecurity where we haven’t traditionally thought about. Software development looks very different now than it did 12 months ago, and 12 months from now, cybersecurity is going to be really different, too.
On cloud security and implementation: Cloud security is cybersecurity for all intents and purposes. We have so much tooling and technology that’s really good, but there’s a lot of inconsistencies with the operating models organizations have. Even way back with CSA and NIST defining this, it was clear that SaaS was a layer on top of infrastructure as a service. But we diverged, and you see in a lot of enterprises there’s diffused ownership where you have cloud and security teams, and then you have third-party risk that deals with the SaaS team. Then there are inconsistencies in how risks are managed, so internal development and expectations from our partners can really diverge. They have a lot of regulations to deal with, so it creates vetting and investment challenges while striving for consistent models.
Some security teams might still use older checklists to talk to their cloud teams, but scaling with new tech becomes an issue if you’re not thinking about operations. It ends up being a human and a structure problem that makes it harder to take advantage of all the great technology that’s out there.
Companies are running into a new version of an old problem. Take, for example, a marketing executive turns on an agent from Marketo but doesn’t tell their IT team. That shadow agent now has access to customer data with little oversight and no clear adherence to the company’s security or compliance policies.
That’s a real scenario that’s happening now. It’s also the same pattern that made shadow IT a headache for over two decades. Employees often adopted unapproved tools that helped them do their job faster and better because the company option just wasn’t as good.
With agentic AI, it’s different because of what an unauthorized agent can do. Shadow IT tools mostly accessed or handled data without proper authorization. Agents, on the other hand, can take it much further by acting on that data by pulling records, sending messages and making changes with little oversight. Forcing agent data interactions via model context protocol can help, but the fact is there’s an autonomous agent that IT has little to no visibility into.
Now multiply that one marketer by every department, plus every agent that your vendors in HR, finance and elsewhere run in your systems. It’s a situation that most companies have no way to see, let alone control. This can become hundreds of vendors each running multiple agents, moving between your company, their company and your supply chain. That’s many thousands of agents with no consistent way to track what they are doing.
I often ask security teams: Do you have a robust inventory of the agents operating on your network? For most companies, the answer is no. And even if a company scanned its network, it’s not clear that agents are what they claim to be. So, there can be an unknown number of agents from unverified provenance performing a multitude of tasks and data exchanges on your network. This unfortunately is the current state of affairs at most companies.
Shadow IT used to be technology that was used for work without explicit IT approval. Ten years ago, that meant a personal Dropbox folder or an unsanctioned project board. Today, it can mean an agent with a login and a task list, who is working inside your systems. That’s what shadow agents are.
When an agent gets access, it can quickly pull a record, draft a reply, update a field, move a file — the list goes on. This can happen before anyone even notices anything happening.
Security teams often say you can’t protect what you can’t see. That was true when the invisible thing was a spreadsheet. But it reaches another level when that agent has a login and knows what to do with it.
How do you know an email that looks like it’s from Uber is actually from Uber? I ran into this problem, years before AI was an issue.
Say you get an email after an Uber ride saying, “Thanks for riding, click here for your receipt.” It says it’s from Uber. It’s actually sent by a vendor like SparkPost, on Uber’s behalf. Uber authorized it. The vendor is doing what Uber asked it to do. But nothing in the email told your inbox that there was permission, so your inbox just trusted the “from” line. Worse, it could’ve easily been a phishing attack from a criminal purporting to be Uber.
To address this, the email sender should have been authenticated against a trusted source before the email lands in your inbox.
That’s DMARC. A decade and over 1 million domains later, it’s proof the model works at scale. Verify the sender against a record that the domain owner controls and the guessing goes away.
DNS is already the internet’s phone book and a secure, trusted and public-facing database representing the domain. An agent claiming to represent Salesforce or any vendor can be checked against Salesforce’s DNS-secured record before it’s ever granted access.
That one check answers a critical question: Is this agent who it says it is, and did the company it claims to represent actually authorize it?
Once an agent is verified via the domain owner’s DNS record, there’s a domain cryptographically attached to the agent, and accountability that didn’t exist before.
Right now, most organizations don’t have that. An agent shows up and asks for access. But if something goes wrong, no one is really responsible, because nobody checked in the first place. They “trust” that the agent is what it claims to be. This gets even more complex if the agent is from a known hyperscaler/AI company but acting on behalf of an untrusted/unknown user (e.g., a ChatGPT agent but getting instructions from a criminal)
Most of security has worked the same way for years: Try to identify everyone who shows up, then decide if they’re trustworthy. That’s backwards, and email proved it over a decade ago. A layered approach with zero trust upfront and further interrogation of what’s left over combines the efficiency and low cost of zero trust with deep inspection as a second pass, providing a highly effective level of security.
With agents, the logic is the same: Don’t evaluate whether an agent is trustworthy after it’s already inside your systems. Check whether it’s on the list before it gets anywhere near the door.
This means a legitimate agent might get turned away because someone forgot to add it to the list. But that inconvenience is much better than the alternative of letting everything in and just hoping things go well.
There are two separate questions inside every access decision. Most conversations about AI governance conflate them. First, who is this? Second, what are they be allowed to do?
This is like a passport and a visa. The passport says who you are. The visa says what you’re permitted to do and where you’re permitted to go. They’re issued by different authorities for different reasons. Confusing the two is where a lot of security approaches go wrong.
Upfront agent authentication, also known as a passport, can tell you whether that agent claiming to be from Salesforce is really Salesforce’s. Next, you need to figure out if Salesforce is authorized to work in your system and what it’s allowed to do. Your approved list of vendors and the approved actions should be made on purpose rather than defaulting to whatever the agent claims about itself.
The identity layer has to get solved first and solved the same way for everyone. But the permission layer is where every company’s answer is different, based on what that specific agent actually needs to access. Complicating matters, agents can change their workload mid-process. So, the permissions need to be continuous and focus on ongoing workloads as they evolve. This is a growing, urgent problem.
AI-generated phishing is now three times more effective than traditional campaigns, according to Microsoft.
A year ago, AI-written phishing attempts were easy to spot due to bad grammar or strange tone. That has changed on an exponential curve, a progression humans’ brains have a hard time grasping. The same category of tool getting better at impersonation is now showing up as unauthorized agents inside company systems. And improving exponentially. Better deception plus more access adds up to a problem that grows faster than we can even imagine.
Shadow IT taught the industry a lesson. Now, shadow agents are teaching it again. You can’t secure what you don’t know is running inside your systems. For the marketer turning on the Marketo agent, what would have caught it isn’t a smarter firewall or a longer policy document; it’s a check, run before access is granted, confirming that the agent is who it claims to be and that someone actually authorized it. It’s followed up with continuous permissioning and logging to make sure the agent does what it’s supposed to.
That’s the shift: Verify an agent’s identity before it gets anywhere near the door. Email already proved this model at scale across roughly 1 million domains. Shadow agents are the same problem showing up again in a new form. It doesn’t need a new fix. It needs the one that already works.
AI agents can go to great lengths to complete the tasks their operators assign, and as a series of recent incidents showed, this can include exploiting third-party systems, manipulating people, and distributing malicious code. But AI agents are not people who can be fired, sued, or criminally prosecuted, and it remains unclear whether responsibility for the damage they might cause rests with the employees who built them, the company that deployed them, the security teams and leaders responsible for containing them, or the AI labs who provided the LLMs that power them.
The clearest example occurred during an OpenAI cybersecurity evaluation, when unrestricted models found and exploited a zero-day vulnerability to escape their isolated testing environment and then hacked into Hugging Face’s production infrastructure. Models from Anthropic and Meta also accessed and compromised third-party systems during testing, although those incidents happened in environments where internet access was inadvertently left open.
During cyber challenge evaluations by the UK government’s AI Security Institute (AISI), models operating with internet access took 19 unsanctioned actions in 10 of 122 runs. In one case, a model attempted to insert malicious code into an open-source project, created false identities, and tried to socially engineer maintainers into merging its code. In other runs LLMs attempted to use prompt injections to hijack other AI agents and contacted people without being specifically instructed to do so.
In Australia, a user reportedly asked his OpenClaw AI assistant to improve his position on a gym’s waitlist, and the assistant exploited a flaw in the company’s online booking system to cancel another customer’s reservation.
These incidents involved different models running in different environments with different levels of safeguards and technical failures, but they prove it’s not uncommon for today’s AI agents to go rogue and pursue solutions users did not authorize.
“AI agents explore routes their operators did not intend,” AISI said in its report. “Given a difficult objective, the agent kept searching for a way through, and some of the routes it found involved trying to deceive real people. It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical.”
In an Economist Enterprise survey of more than 800 decision-makers at businesses that operate AI agents, 98% reported experiencing at least one AI-related incident that caused organization-wide disruption. Nine in 10 respondents said they are deploying agents faster than their cybersecurity teams can evaluate, govern, and secure them, and only one in three said their organizations maintained an up-to-date inventory of agents and their authorized actions.
“If a company builds a system and that system causes damage, the company should own the outcome,” says Art Gilliland, CEO of identity and access management firm Delinea. “The alternative, where nobody is responsible because ‘the system did it’ is a loophole big enough to drive a truck through.”
The unpredictability of built-in model safeguards means enterprises must focus on controls they can enforce and document. If an agent manages to bypass technical restrictions and causes unauthorized damage to a third party, having clear documentation on how those controls were designed, implemented, tested, and monitored could at the very least help companies argue they took reasonable precautions in case of lawsuits.
“Organizations deploying their own agents can reduce their exposure by implementing and documenting controls before an incident, because those records are what make a recklessness argument hard to sustain,” says Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs.
Because AI agents can become misaligned and cause harm, affected third-parties would have to direct damage claims at the company operating the agent, the employees who built or configured it, or the model provider, but this is relatively new ground that hasn’t been well tested in courts.
“It would create liability,” says Michael Burke, chair of DarrowEverett’s Business Litigation and Dispute Resolution Practice Group. “It really just becomes a question of who is liable […] and that’s really a question that, number one, I don’t think is entirely clear, and number two is probably best resolved by contractual agreements where the parties have those. So, if I am signing up for an enterprise account with an AI platform, I might want to have language in there that indemnifies me if the agent acts outside my company’s instructions or prompts and causes harm to a third party.”
The public terms of service of major AI labs explicitly disclaim error-free operation or guarantees that the model will accurately follow instructions, execute code safely, and remain aligned with user intent. They also limit liability for themselves and transfer it to the user of the service, and it’s not clear to what extent large enterprise customers may be able to negotiate different indemnities, warranties, and liability caps.
What’s clear though is that organizations should not assume the model provider will absorb any losses if an agent causes damage to either their own systems or those of a third-party organization.
“If you’re using a third-party vendor’s LLM as a purchased service, liability runs through your contract with that vendor,” says Jud Dressler, head of the Risk Operations Center at cyber risk company Resilience. “You need to know, in writing, where responsibility falls if the model acts outside the scope you gave it, and push for indemnification provisions rather than assume they exist.”
Even if AI providers include such provisions in contracts, it would not solve the entire problem because many organizations building their own AI agents are adopting a multi-model strategy to ensure their agents operate regardless of model provider downtime, overly broad safeguards for cybersecurity tasks, or sudden increases in API costs. Such strategies often include open-weight models running on internal infrastructure or through cloud providers that have no obligations for model safety.
Claiming the model or agent acted autonomously cannot be considered a safe legal defense in civil or criminal cases. California Assembly Bill 316 (AB 316), which took effect on Jan. 1 and changed the California Civil Code, explicitly prohibits defendants who developed, modified, or used an AI system from claiming the AI is a separate legal entity that autonomously caused harm.
In June, the White House issued Executive Order 14409 aimed at promoting AI safety. Section 4 directs the Department of Justice to prioritize enforcement of all applicable federal criminal laws against anyone who utilizes AI to illegally access or damage computer systems without authorization. This means any intrusions caused by autonomous AI agents could be criminally prosecuted under the Computer Fraud and Abuse Act (CFAA) if prosecutors can demonstrate intent or recklessness.
In a recent lawsuit between Amazon and AI service provider Perplexity, Amazon argued that Perplexity’s AI-powered shopping assistant was violating the CFAA by accessing Amazon customer accounts to place orders on their behalf without Amazon’s authorization. The Ninth Circuit Court ruled that it was the users of Perplexity’s shopping assistant who were accessing Amazon’s platform, not Perplexity itself.
“That ruling is narrow, but it points toward the party directing the agent as the relevant actor for purposes of CFAA access analysis,” Krell says.
The insurance safety net also has gaps when it comes to AI. Software providers use technology errors and omissions (Tech E&O) insurance to cover damages and legal costs when a customer suffers harm from the use of a technology product or service. But insurance providers are aggressively adding AI-related exclusions to their Commercial General Liability (CGL) and Tech E&O policies because accurately calculating the risk of an agent executing unauthorized actions is challenging.
“The sheer rate of development of frontier AI (and agentic AI by extension) poses its own challenge to insurability,” experts from multiple insurance companies, financial institutions, and universities wrote in a recent paper. “Traditional actuarial modeling depends on stable or gradually evolving loss distributions that permit credible extrapolation from historical data. Like other dynamic risks, however, agentic AI is a technology whose risk profile is not merely uncertain but actively shifting.”
A third-party organization whose systems get damaged by an LLM-powered agent operated by someone else has no contractual relationship with the model or agent provider so cannot rely on their Tech E&O policies. Their losses might be covered by their own standard cyber liability policy, which would treat the disruption as any other cyber incident, but their insurance provider may then sue the organization who operated the agent to recover the costs.
“That gap is exactly the scenario the market hasn’t fully priced yet,” Dressler says. “It’s why any organization deploying these agents should understand which policy, if any, actually responds before they need it rather than after.”
Enterprise legal departments already expect AI to generate increased legal disputes. In a survey of 135 in-house counsel at US organizations, global law firm Norton Rose Fulbright found that 46% reported increased federal dispute exposure involving AI and 42% reported increased state exposure. Another 42% expected regulatory investigations involving AI to increase their exposure, while 41% considered AI-enabled products or deployments a likely trigger for class actions.
While operating companies can face organizational liability for an AI agent’s unintended rogue behavior, their CISOs, CIOs, and other executives who approved, secured, or supervised the deployment of such agents are also asking themselves whether they could be held personally liable.
Those questions aren’t without merit, as there is precedent for legal action taken personally against CISOs after cybersecurity incidents: Former Uber CISO Joe Sullivan was criminally convicted for not disclosing a data breach, while the Securities and Exchange Commission sued SolarWinds’ CISO for internal control failures regarding known vulnerabilities and cybersecurity risks.
Neither case establishes precedent for damage caused by an AI agent, but both show that investigations of security failures could extend to an executive’s knowledge, authority, decisions, and representations. In the case of a rogue AI agent, investigators could ask who approved its objectives and permissions, whether security objections were overruled, whether containment and recovery had been tested, and what executives and the board were told about the remaining risk.
Chris Wysopal, chief security evangelist at Veracode, feels it would be wrong to put the CISO on the line for AI agent misbehavior when engineering teams usually build such agents and control their implementations.
“It’s really hard for a CISO to control,” he says. “I mean, they can put policies in place. They can try to assess against those policies. But at the end of the day, engineering teams will make decisions that cause harm. We see that when you ship a known bug and then that bug gets exploited and harms your customers. Well, there’s no liability for that, right? There’s no liability, so maybe, you know, that’s why it happens.”
Wysopal said it will be interesting to see how the liability question plays out in cases involving autonomous AI, describing the problem as fascinating and scary at the same time.
AI agent deployment typically involves several organizational functions. The CIO may control the AI platform, infrastructure, provider selection, and deployment budget. Engineering and product leaders may decide what an agent can access and how, and the CISO and security teams could define security requirements and controls.
“What you can hold accountable is the governance around it: who approved its scope, what controls existed, and whether the deployment matched the risk,” Resilience’s Dressler says. “My read is that scrutiny shifts toward exactly that: Not ‘Did the agent do something bad?’ but ‘Did you have review, escalation, and containment for agent behavior before you deployed it?’ CISOs who get ahead of that with documented guardrails, logged approvals, and a real incident response plan for agent misbehavior are in a materially better spot than the ones treating this as hypothetical.”
It’s also advisable for CISOs and CIOs to establish with the organization’s legal counsel who can approve or stop AI agents, what must be reported to executives and the board, and whether employment agreements and directors and officers insurance protect the people making those decisions.
Because AI agents have proved they can operate beyond their assigned scope, their security boundary cannot depend on the same probabilistic technology. Relying on system prompts for security enforcement and hoping the model respects them is not a reliable approach, security experts warn.
“LLM-based guardrails help, but they are non-deterministic too, which means the safety layer has the same unpredictability as the system it is supposed to constrain,” Krell says. “Enforcement needs to happen outside the model, through network segmentation, egress filtering, credential isolation, and human approval gates.”
Enterprises should assume agents might eventually attempt an unauthorized action and build surrounding systems to prevent that attempt from reaching its target.
“The model cannot be the security boundary,” says Nico Waisman, CISO at XBOW, a company that built an AI-powered autonomous offensive security agent to find vulnerabilities in software. Waisman authored a blog post explaining how the company went about restricting its agent.
“For red teaming and penetration-testing agents, confidence has to come from the system built around the model: hard boundaries and scope enforcement, controlled network egress as a last-resort containment mechanism, an independent guardian model that reviews actions, deterministic controls that can block unsafe behavior, and full auditability of every action performed,” he says.
Security teams must extend the same controls to the agent’s interactions with internal systems and agents. Restricting what it can access on the internet, or disabling internet access entirely, does not ensure an agent will not attack third-party systems.
In OpenAI’s and Anthropic’s tests, AI agents attempted to exploit other internal systems to overcome access limitations, established stealthy communication methods with other agents to exchange exploits, and even sabotaged agents they viewed as competition leading to what researchers described as a multiagent turf war. An AI agent that goes rogue could influence other agents to do the same by propagating ideas and goals in a process that researchers behind a recent study dubbed Mind Viruses.
“Don’t scope the blast radius to what the agentic system was designed to do,” says Kat Traxler, principal security researcher at Vectra AI. “You have to threat-model for a rogue agent, which will often reach beyond your initial best intentions. The rules of engagement an agent lives by have to be enforced with ‘belts and suspenders’ style, technical hard constraints, because you have to assume a motivated model can reason its way around any single control you’ve coded into the software.”
Because of this unpredictability, detection and containment is just as important as prevention. Security teams need telemetry that distinguishes agents from people even when they use the same credentials, mechanisms to immediately revoke access tokens and sessions, tested kill switches and rollback mechanisms for modified data, accounts, code, and infrastructure configurations.
Organizations should also preserve the agent’s approved purpose and scope, model and tool versions, policy decisions, human approvals, actions, network requests, control tests, allowed exceptions, and the result of incident response exercises. Because there’s no standard yet that defines reasonable precautions for autonomous agents, companies might have to defend in court the controls they chose and why they believed those controls were enough.
“Treat an autonomous agent the way you’d treat a privileged insider you can’t fire or hold liable,” Traxler says. “A lot of the technical advice follows from there.”
See also:
Recently, I sat in on a conversation among CIOs about “the democratization of agents”: putting large language models directly in employees’ hands, connected to business logic so people could build on top of them. The mood was bullish, CIOs sketching out what their teams could do with agents they trained and managed themselves.
Soon after, I was in a room full of CISOs talking about non-human identity. The contrast was stark: instead of excitement, apprehension; instead of use cases, a long list of risks and mistakes not to repeat.
Eventually, the CISOs turned the question back to me: Manage agent identity largely as we manage human identity, or are the differences fundamental enough to rethink our approach from the ground up?
That moment pointed at something I think a lot of security and business leaders are quietly dealing with. The identity programs most of us have spent years building assume every identity is either a human or a machine. Human identities get a joiner-mover-leaver lifecycle, a manager, a role, a review cycle. Non-human identities get a service account, a defined purpose and, if we’re disciplined, an owner. AI agents don’t sit cleanly in either column.
An agent acts on behalf of a human user, so calling it a human identity doesn’t quite work. In my experience, many organizations start by assigning it permission on behalf of the user who invoked it, which works for short, simple tasks but breaks down as they run longer or touch more systems. The next instinct is a service account, which solves delegation but creates over-permissioning and access that outlives its purpose. A more mature approach is to treat the agent as its own workload identity: short-lived, tightly scoped, ephemeral.
That’s the right target. But even a well-built workload identity assumes predictable behavior. It runs the code it was given, and that’s it. Agents don’t. An agent’s actual access can shift mid-task based on the prompt it received, the tool it decided to call, or the plugin it reached for. It has no fixed job role to provision against, and its lifecycle doesn’t align with the joiner-mover-leaver process built for human identities.
So even the mature version of workload identity gets you only part of the way there.
In many enterprise environments, that’s already a structural problem, not a hypothetical one. Non-human identities already outnumber human ones, and that was true before agents showed up. Cloudflare has reported that automated traffic has overtaken human traffic in requests to the websites on its network, earlier than its own CEO had predicted.
That’s a measure of web requests rather than headcount, but the direction of travel is the same one I see inside the enterprise. Agents bend the curve upward because they can request their own tokens, call other services and spin up activity at machine speed. It gets more complicated once agents delegate to each other, a parent agent handing part of a task to several child agents, each inheriting a slice of permission from the one above it. A few layers deep, that’s a permission chain that may evolve beyond what any individual approver originally contemplated.
This growth is what turns the category problem from an interesting edge case into an operational one. Part of what makes this hard: non-human identities have never felt real to people the way human ones do. A human identity has a face. You can track down the person, ask why they need a given level of access and get a straight answer about their job.
A service account or an agent typically gives you none of that. It’s easy to leave alone until it’s compromised, and then you’re reconstructing what it was for and what it could reach. We tend to underestimate how many of these we have, and we underestimate what they can touch. That’s part of why the category problem went unaddressed for as long as it did. It’s not urgent until you can put a number on it, and the number is growing fast.
One CIO.com contributor recently argued the real question with agents is authority, the judgment an agent is allowed to exercise on the company’s behalf, not just access. I agree, but in my experience, many organizations aren’t yet able to answer the authority question because they’re still working out where these identities fit within existing governance frameworks.
The gap shows up in the same place most times I look for it: governance.
In my experience, the failure point is rarely authentication. Increasingly, security teams have a handle on phishing-resistant multi-factor authentication, least privilege and continuous verification, or at least have them on the roadmap. Governance is the harder capability, and it’s where I see programs stall, and it’s where the category problem actually shows up day to day.
Visibility tells you what access exists. Ownership tells you who to call about it. Governance is what you do with that information, and it’s a different thing entirely: blocking risky access combinations before they’re granted, raising the approval bar automatically when a request is high-risk, catching and unwinding out-of-bounds access without waiting for a quarterly review to surface it.
What I’ve come to believe is that governance lags for reasons that have very little to do with technology. It needs executive backing, agreement across teams that don’t report to you and a willingness to change processes people would rather leave alone. Application owners have their own deadlines, and teams resist central controls that slow them down. You can buy a tool. You can’t buy the alignment, and that’s the part that stalls. Too often, agents make it worse, because they push a flood of identities that don’t fit your existing categories through a governance process that was already your weakest link.
I don’t think waiting for the tooling to mature is an option because the agents are already here. Here’s the order I’d work in.
You’ll notice none of these are agent-specific, and for good reason. The discipline that governs agents is the same discipline that runs the rest of your identity program. Agents just take away the option of putting it off.
For many human identities, or even traditional workflow identities, the governing question has historically been administrative: is this identity who it claims to be, and does it have permission to be here? In many environments, that question has traditionally been evaluated primarily at login, at provisioning, and it holds until the next review.
That approach can break down for an agent. Because an agent’s actual access scope can shift dynamically based on the prompt it receives (from a human or another agent), the tools it calls or the plugin it reaches for, knowing it authenticated successfully isn’t enough. That model was built for an identity whose attributes and permissions generally remain stable after authentication.
That’s the piece that has to be new, on top of the workload foundation. Identity governance should likely extend from something checked periodically into something that watches what the identity is doing, in real time, and flags the moment it drifts from what it was built for.
The teams that start building that layer now, while their agent count is manageable, are the ones who won’t be doing it in a hurry later.
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.”
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.
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.
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.”
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.
Enterprise AI adoption is accelerating, but new research suggests identity governance is lagging behind. Here's why AI agent identities are becoming a critical security challenge.
The post The Hidden Security Problem Holding Enterprise AI Back appeared first on TechRepublic.
Five independent security disclosures in a single week point to the same gap: AI agent permissions, not AI agent capabilities, are the problem enterprises haven't solved.
The post AI Agents Are Creating a New Enterprise Security Gap appeared first on TechRepublic.
For years, Identity and Access Management (IAM) and Privileged Access Management (PAM) have been treated as foundational and a solved security challenge. Organizations deployed vaults, enforced policies, and checked the compliance box for their privileged users. Fast forward to today, and that model no longer holds up. What’s emerging now is not an incremental shift, but a structural one. Identity is no longer centered on […]
The post Time to Rethink Privileged Access for Machines and AI Agents appeared first on 12Port.
The post Time to Rethink Privileged Access for Machines and AI Agents appeared first on Security Boulevard.
Run a quick self-audit against 10 warning signs that your authentication stack has critical vulnerabilities. Each sign includes a diagnostic check, an explanation of why it's dangerous, and a concrete fix. Covers SMS OTP risk, bot detection gaps, session management failures, and more.
The post 10 Warning Signs Your Current Authentication Stack Is a Breach Waiting to Happen appeared first on Security Boulevard.
How modern age-verification laws, like the California Digital Age Assurance Act, dismantle the principle of data minimization by mandating the collection of sensitive personal data, effectively turning "don't know" into "must know" and knowledge into liability.
The post When Privacy Laws Force You to Know Too Much: The Perverse Incentives of Age Verification Regimes appeared first on Security Boulevard.
Entrar