AI Agents and Cybersecurity: Risks for Business

AI agents are crossing permission boundaries

A tool that summarizes a bank statement is different from one that can move money, make purchases, or contact support on your behalf. Once an agent can take actions, its access starts to look less like "integration" and more like "user authority."

That matters because it affects accountability. If an agent operates using a customer's credentials, a bank may struggle to tell whether an action was directly requested, misunderstood, or triggered on its own. Even if the customer agreed to delegate help, the bank still has to protect the account and enforce its own access rules.

AI can help discover vulnerabilities at scale

AI models can support researchers as they analyze code and look for patterns worth investigating. That doesn't mean the model independently proved every reported flaw - or that every AI-generated alert is serious. But once a finding is validated and relates to software that's widely deployed, defenders face the same old problem with a faster clock: patches take time, while disclosure can draw attackers' attention.

AI economics are changing alongside capability

Token prices - the units used to measure model input and output - have fallen across some public benchmarks. Lower prices can make more use cases pencil out. Still, token cost is only part of the bill. Engineering, integration, verification, security controls, and human review all add up.

Read-only access is a useful boundary, not a cure-all

Some banks have authorized - or are moving toward - read-only access. This lets an agent retrieve information without giving it permission to change account state. It meaningfully reduces risk: an agent that can't initiate a transfer has less direct ability to cause financial harm.

But read-only access doesn't remove every issue. It can still expose sensitive financial information, and it doesn't solve questions about identity, data retention, and consent. If you're building financial agents, treat permissions as a set of capabilities - not a single yes-or-no switch:

• Read: View balances, transactions, or statements.
• Prepare: Draft a payment or transfer without submitting it.
• Approve: Ask the customer to confirm a specific action.
• Execute: Complete the approved action through a controlled channel.

The narrower the permission, the easier it is to explain and monitor. For a first release, an agent that prepares an action for a user to approve is usually more defensible than one that executes autonomously.

Credentials are the wrong abstraction for agent access

Handing an agent a person's username and password makes it look like the person. That can undermine multi-factor authentication, make audits harder, and leave the customer with little control over what happens after access is granted.

A better approach is delegated access: a separate identity for the agent, scoped permissions, short-lived authorization, and an audit trail of every action. Not every financial institution offers an easy, standard way to implement that model, and that's part of the problem. Until delegation is widely supported, a customer's willingness to share credentials shouldn't be treated as proof that the integration is secure - or even properly authorized.

Banks are responding to uncertainty by blocking or restricting access. That can frustrate customers and limit useful services, but it's a predictable move when an institution can't confidently answer who is acting, what they're allowed to do, and how to reverse a mistake. The real product challenge is to build a trustworthy permission model - not to assume banks will accept broadly unrestricted agents.

The bottleneck moves from finding bugs to fixing them

For many organizations, identifying a vulnerability is only the beginning. You still have to confirm whether you use the affected component, identify versions in production, test the patch, schedule deployment, and verify the fix worked. In older environments, updates that seem small can break integrations or expose dependencies no one documented.

That's why a vulnerability announcement should trigger a defined response, not a rushed, untracked patch. A practical workflow looks like this:

1. Establish exposure. Inventory the versions and services your organization actually runs.
2. Assess urgency. Use the vendor's advisory and trusted security guidance to understand severity and exploitability.
3. Prioritize reachable systems. Public-facing services and systems holding sensitive data need attention first.
4. Test and deploy the fix. Use a controlled process where you can, but don't let approval cycles create avoidable exposure.
5. Verify the result. Confirm the patched version is running and check for compromise where appropriate.

For the specific PHP issues described in the report, the right move is to consult official advisories and current guidance - not to infer technical details from a summary. The official PHP supported versions page is a good starting point for version support, but it doesn't replace a vulnerability advisory.

AI changes both sides of the security problem

The same tools that help defenders inspect code can also reduce the effort required to search for defects. That doesn't mean every company needs to panic or assume an attack is imminent. It does mean patch management, software inventories, and incident response planning are becoming more valuable - because the pace of vulnerability research is speeding up.

Open-source software is particularly exposed to this imbalance. A small group of maintainers may support code used by millions of websites. AI can increase the volume of findings, but it can't automatically give maintainers more time, more funding, or safer deployment options. Organizations that rely on open-source components should plan for that operational reality rather than treating public code as free infrastructure.

Measure business value, not token volume

More usage doesn't automatically mean more revenue - or better outcomes. The report points to a tension: token usage was rising while business token spending was reportedly flat for two consecutive months. If that gap holds, it could matter to model providers that rely on paid usage. For buyers, it's a reminder that raw usage metrics can hide the financial reality.

A cost model that's actually useful should include more than the provider's token rate:

• Model input and output costs, including cached and uncached tokens.
• Engineering and integration work.
• Human review and correction.
• Security, privacy, and compliance controls.
• The cost of failures, escalations, or incorrect actions.

A low-cost model can make sense for classification or routine drafting. It can be a bad fit for high-impact financial work if it produces unreliable outputs that then require heavy review. On the other hand, using the most expensive model for every task can be wasteful when a smaller model reaches your quality threshold.

The practical approach is to benchmark a workload by outcome. Track cost per successfully completed task, not cost per million tokens. Include latency, error rates, how often humans intervene, and what mistakes cost. Revisit the numbers as pricing and model performance change.

Use a capability ladder

Start with the lowest-risk capability that solves a real user problem, and expand only when the evidence supports it:

1. Inform: Retrieve or summarize information without changing records.
2. Recommend: Suggest an action, with reasoning and relevant context visible.
3. Prepare: Fill in a draft or transaction for a person to review.
4. Execute with approval: Act only after explicit confirmation of the specific action.
5. Execute autonomously: Operate without confirmation only for narrow, reversible tasks with tested safeguards.

This ladder isn't one-size-fits-all. Some tasks are low-impact and easy to undo; others involve money, identity, health, or legal obligations. The right level of human review should track impact and reversibility - not how impressive the technology is.

Make the control plane explicit

Before you release an AI feature, answer these questions in operational terms:

• Identity: Does the system act under its own identity, or does it borrow a user's credentials?
• Scope: What data and actions are allowed, and what is explicitly prohibited?
• Approval: Which actions require human confirmation, and what exactly will the person see?
• Logging: Can you reconstruct what the agent saw, what it decided, and what it did?
• Recovery: Can you revoke access, stop an action, or restore the previous state?
• Cost: Can you measure the full cost per useful outcome, including review and failure handling?

If you can't answer these clearly, the system isn't ready for broader autonomy. That's true even if the model performs well in a demo. Real production brings unexpected inputs, partial outages, ambiguous requests, and users who reasonably assume the product will behave differently than it actually does.

Plan for the day after

The bank reporting is really about preparation for scenarios where access needs to be secured or restored quickly. That's a useful pattern beyond financial services. Teams should plan not just for a smooth launch, but for the first incident: a mistaken action, weird agent behavior, compromised credentials, or a newly disclosed vulnerability in a dependency.

A practical plan spells out who can disable the feature, how users are notified, what logs are kept, and how affected accounts or data are recovered. It also defines what evidence triggers a shutdown. A kill switch that no one is allowed to use isn't a control - it's a checkbox.