The Next Cybersecurity Challenge Is Already Inside Your Business
For decades, cybersecurity has focused primarily on protecting human users, devices, networks and applications.
We authenticate employees, restrict administrative privileges, monitor suspicious logins and implement increasingly sophisticated identity and access management systems.
But a new participant has entered the workplace: the autonomous AI agent.
Unlike traditional chatbots that respond to questions, modern AI agents can interact directly with business systems. Depending on their configuration, they may read emails, update customer records, generate invoices, execute software deployments, retrieve financial information or communicate with external services.
These capabilities offer substantial productivity benefits. They also introduce a fundamental security question:
What happens when an AI system has the technical ability to perform actions that its human operator never explicitly authorised?
This October, during Cybersecurity Awareness Month, AckerWorx examines why AI agents must become first-class identities within modern security architectures.
The central principle is straightforward: an AI agent should never possess more authority than its assigned task requires.
1. AI Has Evolved From Assistant to Actor
Traditional software applications generally operate according to predefined instructions. While their behaviour can be complex, their permitted operations are usually established through application logic.
Agentic AI introduces a different operational model.
An AI agent may interpret a high-level objective, decide which tools to use, retrieve information from multiple systems and determine its next action based on intermediate results.
Consider a business owner asking an AI assistant:
"Review outstanding invoices, contact customers with overdue payments and update our accounting records."
A sufficiently integrated AI agent could potentially:
Query customer and invoice databases.
Identify overdue accounts.
Retrieve customer contact information.
Generate and send payment reminders.
Update accounting records.
Trigger additional workflows.
Each step represents an interaction with a system containing information or capabilities that may need protection.
The problem is not necessarily that the agent intends to act maliciously. It is that natural-language instructions are not a reliable substitute for technical authorisation controls.
An ambiguous instruction, compromised external document or incorrectly configured tool could cause an agent to perform an unintended operation.
An AI agent's ability to reason about an action should never be confused with its authority to execute that action.
2. Every AI Agent Needs Its Own Identity
One of the most dangerous architectural shortcuts is allowing AI agents to operate using unrestricted human credentials.
Imagine a developer connecting an AI coding assistant to a production environment using an administrator's API token.
The agent may only need permission to retrieve application logs. However, if its credentials also permit database deletion, account creation and infrastructure changes, those capabilities remain technically accessible.
This violates a longstanding principle of cybersecurity: least privilege.
Instead, organisations should adopt a structured identity model that distinguishes between the person requesting an operation and the software performing it.
Human identity → Application identity → Agent identity → Authorised action
Each component should be identifiable, authenticated where appropriate and subject to enforceable permissions.
For example, an invoicing agent might receive permission to read invoices and prepare reminders, but not to issue refunds or modify banking details.
An AI software-development agent might receive access to a test environment while remaining unable to deploy directly into production.
Separating these identities provides more than improved security. It establishes accountability.
When something goes wrong, an organisation should be able to determine which agent executed an action, who initiated it and what authority was granted.
3. Zero Trust Must Extend Beyond Human Users
Zero Trust security is built around a simple assumption: access should never be granted merely because an entity exists inside a trusted environment.
This principle becomes particularly important when working with autonomous AI.
An agent operating within a corporate network should not automatically gain access to every connected application or database.
Likewise, successful authentication should not provide unrestricted authority for the duration of an entire workflow.
Instead, access decisions should consider the agent's identity, the initiating user's authority, the requested operation, the resource being accessed and the operational context.
Consider an AI customer-support agent.
Reading a customer's recent support tickets may be a normal part of its responsibilities. Changing that customer's account ownership or exporting the entire customer database should require entirely different permissions.
These restrictions should exist at the application and API level, rather than relying exclusively on instructions embedded within the AI system.
A secure architecture does not ask the AI whether it is permitted to perform an operation.
It independently verifies that permission before allowing the operation to proceed.
4. Prompt Instructions Are Not Security Controls
One misconception surrounding AI security is the belief that sufficiently detailed system instructions can prevent dangerous behaviour.
Developers may configure an agent with instructions such as:
"Never access confidential information."
"Do not modify production records."
"Always request permission before transferring money."
Such instructions can guide intended behaviour, but they cannot provide the same security guarantees as enforced access controls.
AI systems can encounter conflicting instructions, manipulated content or malicious input embedded within external documents and web pages.
This introduces the risk of prompt injection.
For example, an agent legitimately summarising a supplier document might encounter hidden instructions directing it to disclose internal information or invoke an unrelated tool.
The document is data, not an authorised source of operational commands. Yet an insufficiently protected agent may confuse those boundaries.
Defensive measures should therefore include restricted tool access, input trust boundaries, independent authorisation, validation of requested operations and monitoring of anomalous behaviour.
If an AI agent is instructed not to delete records, the most reliable protection is to ensure its credentials do not permit deletion in the first place.
Security should remain effective even when the AI's instructions are misunderstood or manipulated.
5. Short-Lived Credentials Should Become the Default
Credentials represent another significant risk.
Many software integrations continue to depend on static API keys and long-lived service-account secrets.
When these credentials are exposed, attackers may retain access until the affected credentials are revoked or expire.
For AI agents, this risk becomes more pronounced when tools, external services and automated workflows are connected.
A safer approach uses narrowly scoped, short-lived credentials wherever supported.
For example, an agent authorised to retrieve invoices should receive credentials limited to the required accounting resource and permitted operations.
When its assignment finishes, that authority should expire or be revoked.
Modern authentication mechanisms, including OAuth-based delegated access and workload identity systems, can help establish these boundaries.
Organisations should also maintain reliable credential rotation, secure secret storage and mechanisms for immediate revocation.
An AI agent should borrow precisely the authority it needs, for only as long as it needs it.
6. Every Agent Action Must Be Auditable
As autonomous systems take on more responsibility, organisations must be able to reconstruct their actions.
Traditional application logs often indicate which API endpoint was accessed or whether an operation succeeded.
However, agentic systems introduce additional questions.
What prompted the agent to perform that action? Which human or system initiated the workflow? Which tools were available? Was the operation authorised? Did the agent attempt something outside its assigned privileges?
A meaningful agent audit record should capture:
The agent's unique identity and relevant version.
The initiating user, service or workflow.
The requested operation and target resource.
The permissions and approval context.
The action's outcome, including denied attempts.
Timestamps, correlation identifiers and relevant security events.
Sensitive data should be minimised or redacted in logs, while the audit records themselves should be protected against unauthorised alteration.
This provides essential visibility for incident investigation, compliance reviews and operational troubleshooting.
It also creates the foundation for detecting potentially compromised or misbehaving agents.
An invoicing agent suddenly attempting to access authentication settings, for example, should raise an immediate security concern.
7. Human Approval Still Matters
Automation does not eliminate responsibility.
Some activities carry financial, operational or legal consequences that justify additional safeguards.
Examples include transferring funds, deleting critical records, changing security permissions, publishing sensitive information and deploying changes to production infrastructure.
These operations should be governed by explicit policies.
Depending on their sensitivity, they may require approval from an authorised person before execution.
Importantly, a human approval workflow should verify what is actually going to happen.
An approval request that simply says "Allow AI to continue" provides little meaningful protection.
A better request identifies the operation, affected resources, expected impact and identity requesting authorisation.
Approvals should also be bound to the specific operation being reviewed. An agent should not be able to obtain approval for one action and subsequently substitute a materially different action.
Human oversight works best when it is deliberate, understandable and technically enforceable.
8. Organisations Need an AI Kill Switch
Even a carefully designed agent can malfunction, encounter compromised data or behave unexpectedly.
Security teams must therefore retain the ability to contain an agent without unnecessarily disrupting the broader application.
A practical containment capability should allow authorised operators to disable an agent identity, revoke active credentials, block its tool access and stop queued or ongoing actions wherever technically possible.
Revoking a token alone may not stop a request already accepted by a downstream service. Effective containment may require controls at several layers.
This is especially relevant for agents operating across multiple systems.
If suspicious activity is detected, administrators should not have to shut down an entire customer-facing platform simply to prevent one automation from continuing.
Agent-level isolation and revocation should be part of the architecture from the beginning.
9. Security Monitoring Must Adapt to Machine Behaviour
Traditional monitoring commonly focuses on suspicious login locations, malware activity, unauthorised network connections and unusual human account behaviour.
AI agents introduce additional behavioural patterns worth evaluating.
An agent may authenticate successfully, possess valid credentials and still perform actions that are abnormal for its assigned purpose.
For example, an agent normally responsible for creating support tickets might suddenly attempt hundreds of customer-data exports.
Every individual API request could appear technically valid, while the overall behaviour indicates a potential compromise or serious configuration problem.
Detecting this requires more than authentication logs.
Organisations need visibility into the relationship between agent identities, permission scopes, tool invocations, resource access and operational context.
Modern analytics can help identify anomalies, but security decisions should remain grounded in enforceable policy.
Monitoring should complement authorisation, not replace it.
10. The AckerWorx Perspective: Security Must Follow the Action
At AckerWorx, we believe effective security should be embedded into the architecture of connected systems rather than added as an afterthought.
The emergence of autonomous AI reinforces the importance of several fundamental engineering principles.
Identity must be explicit. Every participating human, application and agent should have an identifiable role within the security model.
Authorisation must be enforced. Sensitive operations should be evaluated against permissions rather than accepted because an agent requested them.
Activity must be observable. System operators should have sufficient visibility to investigate events, understand automated workflows and identify abnormal behaviour.
Control must remain reversible. Access can be granted for legitimate purposes, but it must also be possible to revoke that access quickly.
These principles align with the wider architectural direction behind AckerWorx initiatives, including Identity Worx and the Signal platform's event analytics and security-monitoring capabilities.
They also apply far beyond AI.
Whether an organisation operates a point-of-sale platform, SaaS application, connected marketplace or internal business system, the underlying security requirements remain remarkably consistent.
The system performing an action must have an appropriate identity, a defined level of authority and a traceable operational history.
11. What Businesses Should Do Now
Organisations do not need to wait for an AI-related incident before reviewing their security architecture.
A practical starting point is to inventory existing AI agents and automated integrations, including the external tools and credentials they can access.
From there, security and engineering teams should identify workflows that operate through shared administrator accounts or unnecessarily broad service credentials.
These access paths should be replaced with dedicated identities and appropriately scoped permissions.
Businesses should also examine which operations require explicit approval, whether agent activity is sufficiently logged and how quickly access could be revoked during an incident.
Finally, security testing should include attempts to manipulate agent behaviour through untrusted content and attempts to access resources beyond authorised boundaries.
The goal is not to eliminate automation.
It is to ensure that automation operates within defined, observable and enforceable limits.
Conclusion: The Future of Identity Is No Longer Exclusively Human
Artificial intelligence is changing how software interacts with the world.
As agents acquire the ability to execute code, communicate with services and make operational decisions, they are becoming active participants in digital infrastructure.
That evolution requires a corresponding change in cybersecurity architecture.
Organisations must move beyond treating AI as an isolated application feature and recognise the security implications of granting autonomous systems operational authority.
Unique identities, least-privilege authorisation, short-lived credentials, comprehensive auditing and effective revocation are becoming essential building blocks for trustworthy agentic systems.
The most important lesson is not that AI systems should be prevented from taking action.
It is that their authority must remain measurable, limited and accountable.
Don't just secure the AI. Secure what the AI is allowed to do.
Published by AckerWorx as part of our October 2026 Cybersecurity Awareness Month coverage.
AckerWorx — Engineering connected systems with security, privacy and accountability at their foundation.
Share this article
Stay ahead of the threat
Breaking news, advisories and field reports from AckerWorx, straight to your inbox.