AI Agent Security: Enforce MFA, Least Privilege and Access Reviews

That was the thrust of a HumanX Amsterdam panel reported by PCMag’s Rob Pegoraro: familiar security failures deserve attention before hypothetical robot overlords monopolize the conversation. Noma Security’s Diana Kelley, Tenable’s Eric Doerr, and Aikido co-founder Madeline Lawrence emphasized excessive permissions, missing authentication controls, and neglected weaknesses. Their argument was about priorities—not proof that autonomous AI presents no danger.

For enterprise IT administrators and software developers, the practical takeaway is straightforward: AI governance needs to reinforce security fundamentals, not replace them with a new vocabulary.

The old weaknesses have not retired​

According to PCMag, Doerr described customers at opposite ends of the maturity spectrum: some still lacked MFA, while more sophisticated organizations gave AI systems too much freedom. Lawrence similarly urged attention to known, unresolved problems. These were practitioners’ observations, not a survey establishing how prevalent each failure is.

Independent guidance supports the authentication priority. CISA recommends requiring MFA across business email, file storage, and remote access, starting with administrator accounts and people handling sensitive data. It also recommends aiming for phishing-resistant authentication rather than treating every second-factor method as equally strong.

That gives administrators a useful starting point:

• Confirm which important systems actually require MFA.
• Prioritize privileged accounts, sensitive-data access, and remote connections.
• Use phishing-resistant methods where supported.
• Where stronger authentication is not yet available, improve existing methods rather than leaving accounts password-only.

CISA describes number matching as an interim improvement while organizations work toward phishing-resistant MFA. Its guidance also distinguishes stronger options, such as security keys, from weaker text or email codes.

The distinction matters: authentication protects access to an account. It does not, by itself, determine whether an authenticated agent—or someone influencing that agent—should be allowed to retrieve a particular document.

The GitHub example: whose authority is being used?​

Noma’s research provides a more precise explanation of the permissions problem raised at the panel.

The company describes “workflow identity hijacking”: an automation receives a request from someone with limited or no authority, then performs the requested operation using a more privileged service identity. The model need not be persuaded to disregard its instructions. It can follow them correctly while the surrounding application makes the wrong authorization decision.

In Noma’s account of its GitHub research, an issue-assignment workflow read an issue and posted a response. Because the examined agent could read repositories across the organization, external users could exploit the workflow to obtain private-repository information. This is a finding about the researched workflow and its access boundaries—not evidence that every GitHub Agentic Workflow exposes confidential code.

Consider the underlying distinction: a request to summarize private information may be legitimate when it comes from an authorized employee and illegitimate when it comes from an outsider. The wording can be identical. Noma’s point is that filtering suspicious language cannot substitute for checking the requester’s authority.

That is the “confused deputy” concern in practical terms: a system with legitimate access becomes a route through which somebody else exercises that access.

GitHub’s safeguards are relevant—but not a blanket guarantee​

GitHub’s own security-architecture explanation, published March 9, 2026, explicitly treats autonomous agents as untrusted, particularly when they encounter externally supplied content. The architecture separates agent execution from privileged operations through container isolation, controlled network access, credential separation, staged writes, and extensive logging.

GitHub also describes a safe-outputs process that constrains which updates an agent can propose and vets them before execution. Those protections address important risks, but they should not be read as proof that every deployment has the correct repository scope or authorization model.

The practical implication of comparing GitHub’s architecture with Noma’s finding is to review two separate questions:

1. What can the agent access?
2. Who can influence how it uses that access?

Read-only access still deserves scrutiny. Preventing edits does not automatically prevent disclosure.

Shadow AI is also a remote-access problem​

PCMag recounts Doerr’s example of a contractor installing an unauthorized OpenClaw agent and connecting a personal Telegram account to control it remotely. The customer was unnamed, and the report supplied no forensic record establishing a breach. It is best understood as an attributed account of unmanaged access, not a demonstrated vulnerability in either product.

OpenClaw’s documentation independently establishes that Telegram messages can pass through a gateway to an agent, which can then invoke tools on connected nodes. That makes chat-based control technically plausible; it does not verify the contractor incident or its exact configuration.

The administrative lesson is broader than one assistant. When a personal messaging account becomes a control channel for software operating on company resources, IT needs to understand the resulting access path.

As an operational recommendation drawn from this example, an AI inventory should record more than product names. It should identify:

• The deployment’s owner and business purpose.
• Its execution identity and available permissions.
• Connected repositories, files, services, and tools.
• Messaging integrations and other remote-control channels.
• How access can be revoked and activity investigated.

A sanctioned route for useful automation is part of the answer. Otherwise, a policy may prohibit an agent while offering employees no workable alternative—and convenience will continue auditioning for the role of security architect.

AI-assisted discovery does not mean bug-free software​

There is a counterweight to the panel’s warnings: AI can help security teams find defects.

Google Threat Intelligence Group’s September 30, 2026, report examined vulnerability disclosure and exploitation trends. It reported that monthly disclosures increased from 5,045 in January to 10,740 in August, while the average number of vulnerabilities exploited per month rose from 10.5 in 2025 to 18 during January–August 2026. Google characterized AI as measurably changing the vulnerability landscape. Those aggregate figures should not be interpreted as proof that AI discovered or caused every vulnerability counted.

More discovery creates opportunities to fix problems, but it also creates remediation work. CISA’s established guidance remains relevant: keep software updated and prioritize known-exploited vulnerabilities, especially on internet-facing systems.

PCMag reports that the panelists rejected the expectation of automatically bug-free software. Kelley also criticized insecure AI-generated code, although her comments were not a quantified study of all AI-assisted development.

For development teams, the reasonable conclusion is to retain review, testing, and deployment controls regardless of who—or what—produces a change. GitHub’s decision to stage and vet agent-generated writes illustrates that principle in product architecture.

Fix the baseline—and enforce the boundaries​

The strongest reading of the Amsterdam discussion is not “ignore AI risk.” It is “do not let AI risk distract you from controls that already have an actionable purpose.”

Start with MFA coverage. Review what agents can read and change. Check whose authority workflows use. Inventory unofficial deployments and their control channels. Keep patching obligations visible.

Then address the additional challenge of agents interpreting untrusted material and proposing actions. Authentication, authorization, isolation, output review, and logging solve different parts of that problem; none is a universal replacement for the others. CISA’s authentication guidance, Noma’s authorization research, and GitHub’s execution safeguards together make that distinction concrete.

The robot-overlord debate can wait through an access review. The overprivileged automation already holding the keys cannot.