Cisco’s latest AI security message is less about a single product launch than a hard business reality: enterprises cannot treat agentic AI, cybersecurity, infrastructure spending, and geopolitical competition as separate agendas. As AI systems move from answering questions to taking actions across networks, code repositories, cloud platforms, and business applications, the cost of weak security rises just as sharply as the cost of the underlying compute.
Jeetu Patel, Cisco’s President and Chief Product Officer, has framed the challenge in direct terms. Organizations are making forward investments in both cybersecurity and AI efficiency because neither discipline is optional. That position matters for Windows administrators, IT leaders, developers, and security teams that increasingly face pressure to deploy AI copilots and autonomous agents without opening new pathways to ransomware, data loss, privilege misuse, or costly operational mistakes.
The wider conversation also reaches beyond corporate budgets. China’s accelerating AI model development, particularly around openly available model weights and efficient architectures, is forcing American technology companies to reconsider how openness, security, and commercial advantage can coexist. Cisco’s stance suggests that security will become a defining factor in this race—not merely a compliance checkbox added after models and agents reach production.
For years, AI security discussions often focused on familiar concerns: prompt injection, sensitive-data exposure, hallucinated output, model bias, and insecure APIs. Those issues remain important, but they do not fully describe the new risk profile facing enterprises.
The arrival of agentic AI changes the equation. An AI agent may retrieve information from a knowledge base, search a cloud drive, query an internal database, generate a script, change a ticket, trigger a workflow, communicate with another agent, or make recommendations that lead to an automated action. In many cases, it can chain those activities together.
That is a fundamental shift from a chatbot that simply produces text.
A traditional generative AI assistant can be wrong in a visible way. An autonomous or semi-autonomous agent can be wrong while holding credentials, invoking tools, reading enterprise data, and operating at machine speed. The difference is not academic. It determines whether an error becomes an inconvenient answer or an incident requiring containment, forensics, recovery, and executive disclosure.
Cisco’s growing emphasis on AI security reflects the fact that AI is becoming part of the enterprise operating model. The network, identity platform, endpoint estate, collaboration suite, cloud environment, and security operations center are all becoming places where AI tools can observe, recommend, and act.
For Windows environments, that means AI security will increasingly overlap with everyday administrative concerns:
That workflow may be useful. A security agent could investigate suspicious activity, correlate indicators across logs, identify affected endpoints, recommend containment actions, and draft an incident summary. An IT operations agent could review alerts, diagnose a service issue, open a change record, or automate low-risk remediation.
The same capabilities also create new attack opportunities.
If an agent can use a browser, access documentation, search email, read files, call APIs, execute code, or modify configurations, malicious content may try to influence its choices. Attackers do not necessarily need to compromise the model itself. They may instead manipulate the information the model reads, the tool it selects, the task it interprets, or the permissions it inherits.
For a simple chat interface, the result may be an unhelpful or inappropriate response. For an agent connected to enterprise tools, the stakes are higher.
An unsafe agent might be persuaded to:
An agent should not receive standing administrative privileges simply because it might need access someday. It should have a narrowly defined role, a defined set of allowed tools, strict data boundaries, and time-limited elevation when needed.
This is the logic behind applying zero-trust security to AI agents. Every identity, request, tool call, and sensitive action should be subject to verification and policy enforcement.
For example, a Windows endpoint remediation agent could be allowed to collect diagnostics and recommend a fix. It might also be allowed to restart a specified service after approval. It should not automatically be able to alter domain policies, disable endpoint protection, create privileged accounts, or push unreviewed scripts across the organization.
That difference separates useful automation from uncontrolled autonomy.
The significance of this approach is that it moves beyond a narrow “secure the model” mindset.
A large language model does not operate in isolation. It depends on prompts, retrieval systems, vector databases, APIs, plug-ins, agent frameworks, model providers, cloud services, code repositories, datasets, and permissions. Each component can introduce risk.
An organization may carefully validate a model provider while overlooking a risky third-party connector. It may place guardrails around prompts while allowing an agent to access a sensitive SharePoint library through an overly permissive service account. It may inspect its own code but neglect the integrity of a package, plug-in, model artifact, or tool definition pulled into the environment.
Cisco’s focus on AI supply-chain governance is therefore timely. The supply chain is no longer only about open-source libraries and software dependencies. It includes the information, instructions, capabilities, and identities that make AI systems operational.
Effective runtime controls should help security teams answer critical questions:
The ideal architecture connects agent activity with endpoint, network, identity, cloud, and application telemetry. Without that correlation, teams may see a suspicious API call or data transfer but lack the context needed to identify whether an AI agent initiated it, what prompted it, and whether it acted within policy.
That is a sensible comparison.
Cloud adoption did not eliminate the need for security investment. It forced organizations to rethink security architecture. Identity became more central. Network perimeters became less reliable. Logging, encryption, configuration management, and shared-responsibility models grew more important.
AI is likely to create a similar transition.
Security is not separate from AI value realization. It is one of the conditions for achieving it.
An AI system that cannot handle sensitive data safely will be restricted to low-value tasks. An agent that lacks reliable access controls cannot be trusted with meaningful workflow automation. A company that cannot explain what an agent did will struggle to use that agent in regulated, customer-facing, or high-impact processes.
This means security investment can increase the range of AI use cases that an organization can responsibly pursue.
The most common trap is measuring success through activity rather than outcomes.
An enterprise may celebrate the number of employees with AI access, the number of agents created, or the volume of prompts submitted. Those metrics say little about whether the organization is producing value.
More useful measures include:
An agentic system can consume far more tokens and compute than a single user query. It may inspect documents, reason over a task, call tools, validate intermediate output, retry failed steps, invoke other agents, and maintain contextual state. Each of those activities contributes to latency and cost.
This does not make agentic AI a bad investment. It means enterprises need realistic expectations.
AI leaders should distinguish between:
Smaller or specialized models may be appropriate for:
This is where the connection between AI efficiency and cybersecurity becomes especially strong. A well-designed system can reduce cost and risk at the same time. It can route routine tasks to smaller models, require approval for high-impact actions, use policy enforcement before tool execution, and maintain a complete audit trail.
Specialized models can be valuable because they are tuned for a defined security problem. In vulnerability management, the question is not merely whether a known CVE exists in theory. Teams need to understand whether the affected component is present, reachable, exploitable in context, and urgent enough to prioritize.
That is where AI-assisted code and repository analysis can help.
But the value depends on verification. A security AI tool should accelerate investigation, not become an unquestioned authority.
An AI model can misinterpret code, overstate confidence, overlook environmental context, or produce a plausible but incorrect explanation. When the output is used to prioritize remediation, communicate risk, or approve an action, human review remains essential.
The strongest deployment pattern is usually human-led, AI-accelerated security operations:
China’s AI ecosystem has demonstrated that innovation can come from architectural efficiency, training methods, engineering discipline, and open distribution—not only from matching the largest U.S. infrastructure investments dollar for dollar.
That has implications for enterprise buyers.
That distinction matters for governance, compliance, and security.
Organizations should not assume that an openly available model is automatically transparent, safe, auditable, or free of licensing constraints. They should evaluate:
However, open availability also lowers barriers for malicious use. Security teams must be realistic about that tension.
The appropriate response is not simplistic. It is not “all AI should be closed,” nor is it “all models should be released without safeguards.” The better approach is risk-based.
Lower-risk models, tools, datasets, and defensive capabilities can often benefit from wider availability. More capable systems that materially increase cyber, biological, fraud, or autonomy-related risks may require stronger controls, staged access, or more limited release strategies.
For the United States, the strategic argument for open AI is compelling when it expands the adoption of trusted American technology, development tools, infrastructure, and standards. But that argument only succeeds if openness is paired with credible security practices, clear licensing, high-quality documentation, and a serious commitment to trustworthy deployment.
Maintain an inventory that records:
Use least privilege, short-lived tokens where possible, segmented access, strong authentication for sensitive operations, and explicit approval steps for elevated actions. Monitor agent behavior as closely as the behavior of privileged users and service accounts.
Low-risk activities may be automated, such as drafting a summary, categorizing a ticket, or gathering diagnostic information. Moderate-risk activities may require review, such as creating a change request or generating a remediation script. High-risk activities should require explicit human approval, including account changes, policy modifications, production deployments, financial actions, destructive commands, or external data sharing.
This design preserves the productivity benefits of AI while preventing a single flawed reasoning chain from becoming a business-impacting event.
Test scenarios should include:
AI agents may become powerful operational tools in security, IT administration, software development, customer support, and enterprise workflow automation. But that power comes from access—to data, systems, tools, and identities. The more useful the agent becomes, the more carefully it must be governed.
The same principle applies to the global AI race. Open models, efficient architectures, and broad developer ecosystems can accelerate innovation and strengthen competitiveness. Yet openness without security discipline can create new risks for enterprises and governments alike.
For Windows and enterprise IT teams, the practical path is not to delay AI indefinitely or to deploy agents without restraint. It is to build AI systems around least privilege, continuous verification, runtime visibility, measurable business value, and human accountability. The organizations that do so will be better positioned to capture AI’s benefits without turning their own infrastructure into the proving ground for the next generation of cyber threats.
Jeetu Patel, Cisco’s President and Chief Product Officer, has framed the challenge in direct terms. Organizations are making forward investments in both cybersecurity and AI efficiency because neither discipline is optional. That position matters for Windows administrators, IT leaders, developers, and security teams that increasingly face pressure to deploy AI copilots and autonomous agents without opening new pathways to ransomware, data loss, privilege misuse, or costly operational mistakes.
The wider conversation also reaches beyond corporate budgets. China’s accelerating AI model development, particularly around openly available model weights and efficient architectures, is forcing American technology companies to reconsider how openness, security, and commercial advantage can coexist. Cisco’s stance suggests that security will become a defining factor in this race—not merely a compliance checkbox added after models and agents reach production.
AI Security Is Becoming an Infrastructure Decision
For years, AI security discussions often focused on familiar concerns: prompt injection, sensitive-data exposure, hallucinated output, model bias, and insecure APIs. Those issues remain important, but they do not fully describe the new risk profile facing enterprises.The arrival of agentic AI changes the equation. An AI agent may retrieve information from a knowledge base, search a cloud drive, query an internal database, generate a script, change a ticket, trigger a workflow, communicate with another agent, or make recommendations that lead to an automated action. In many cases, it can chain those activities together.
That is a fundamental shift from a chatbot that simply produces text.
A traditional generative AI assistant can be wrong in a visible way. An autonomous or semi-autonomous agent can be wrong while holding credentials, invoking tools, reading enterprise data, and operating at machine speed. The difference is not academic. It determines whether an error becomes an inconvenient answer or an incident requiring containment, forensics, recovery, and executive disclosure.
Cisco’s growing emphasis on AI security reflects the fact that AI is becoming part of the enterprise operating model. The network, identity platform, endpoint estate, collaboration suite, cloud environment, and security operations center are all becoming places where AI tools can observe, recommend, and act.
For Windows environments, that means AI security will increasingly overlap with everyday administrative concerns:
- Active Directory and Microsoft Entra ID permissions
- Windows endpoint configuration and patch management
- PowerShell automation
- Microsoft 365 data access
- SharePoint and OneDrive permissions
- Teams-based workflows and integrations
- Security event monitoring through SIEM and XDR platforms
- Privileged access management
- Remote administration and service-account governance
Why AI Agents Create a Different Attack Surface
From assistant to actor
The term agent is often used loosely, but its enterprise meaning is becoming more specific. An AI agent is generally a system that can reason through a task, select or invoke tools, use contextual information, assess intermediate results, and continue through a workflow with limited human intervention.That workflow may be useful. A security agent could investigate suspicious activity, correlate indicators across logs, identify affected endpoints, recommend containment actions, and draft an incident summary. An IT operations agent could review alerts, diagnose a service issue, open a change record, or automate low-risk remediation.
The same capabilities also create new attack opportunities.
If an agent can use a browser, access documentation, search email, read files, call APIs, execute code, or modify configurations, malicious content may try to influence its choices. Attackers do not necessarily need to compromise the model itself. They may instead manipulate the information the model reads, the tool it selects, the task it interprets, or the permissions it inherits.
The prompt injection problem is only the beginning
Prompt injection remains one of the most recognizable AI security risks. It occurs when hostile instructions are embedded in content that the AI system processes. A malicious webpage, document, ticket comment, email, or knowledge-base entry might attempt to override the agent’s intended task.For a simple chat interface, the result may be an unhelpful or inappropriate response. For an agent connected to enterprise tools, the stakes are higher.
An unsafe agent might be persuaded to:
- Reveal information it should have kept private
- Search sources outside the permitted scope
- Exfiltrate data through an approved-looking channel
- Make harmful tool calls
- Use overly broad credentials
- Alter a configuration or workflow
- Trust malicious content as an operational instruction
- Create or approve actions without proper review
Agent privilege must be narrower than human privilege
One of the biggest mistakes organizations can make is giving an AI agent the same broad access that an administrator or senior analyst holds. It may feel convenient, especially during pilot projects, but it creates an unacceptable blast radius.An agent should not receive standing administrative privileges simply because it might need access someday. It should have a narrowly defined role, a defined set of allowed tools, strict data boundaries, and time-limited elevation when needed.
This is the logic behind applying zero-trust security to AI agents. Every identity, request, tool call, and sensitive action should be subject to verification and policy enforcement.
For example, a Windows endpoint remediation agent could be allowed to collect diagnostics and recommend a fix. It might also be allowed to restart a specified service after approval. It should not automatically be able to alter domain policies, disable endpoint protection, create privileged accounts, or push unreviewed scripts across the organization.
That difference separates useful automation from uncontrolled autonomy.
Cisco’s AI Security Direction: Guardrails at Runtime
Cisco’s AI security strategy increasingly centers on protecting AI applications and agentic workflows across their lifecycle. That includes securing the AI supply chain, monitoring runtime behavior, governing agent interactions, and applying identity-aware controls as agents use enterprise tools.The significance of this approach is that it moves beyond a narrow “secure the model” mindset.
A large language model does not operate in isolation. It depends on prompts, retrieval systems, vector databases, APIs, plug-ins, agent frameworks, model providers, cloud services, code repositories, datasets, and permissions. Each component can introduce risk.
The supply-chain problem
Modern AI applications are assembled from many layers:- A foundation model, whether hosted, proprietary, locally deployed, or open-weight
- An agent framework or orchestration platform
- Retrieval-augmented generation components
- Data connectors
- Tool integrations and APIs
- Credentials, service principals, and tokens
- Custom code and workflow logic
- Runtime infrastructure
- Monitoring and logging systems
An organization may carefully validate a model provider while overlooking a risky third-party connector. It may place guardrails around prompts while allowing an agent to access a sensitive SharePoint library through an overly permissive service account. It may inspect its own code but neglect the integrity of a package, plug-in, model artifact, or tool definition pulled into the environment.
Cisco’s focus on AI supply-chain governance is therefore timely. The supply chain is no longer only about open-source libraries and software dependencies. It includes the information, instructions, capabilities, and identities that make AI systems operational.
Runtime protection matters more than static policy
Static rules are valuable, but they are not enough for autonomous workflows. An agent may encounter unexpected content, shift to an unanticipated task path, or repeatedly attempt a blocked action. The organization needs visibility into behavior as it happens.Effective runtime controls should help security teams answer critical questions:
- Which model or agent made this request?
- On whose behalf was it operating?
- What data did it access?
- Which tools did it invoke?
- What permissions did it use?
- Was the action within its assigned purpose?
- Did it attempt to send data outside approved boundaries?
- Can the activity be traced and audited afterward?
The ideal architecture connects agent activity with endpoint, network, identity, cloud, and application telemetry. Without that correlation, teams may see a suspicious API call or data transfer but lack the context needed to identify whether an AI agent initiated it, what prompted it, and whether it acted within policy.
Security Spending Does Not Have to Cannibalize AI Investment
Patel’s most consequential observation may be his insistence that increased spending on cybersecurity is not necessarily taking money away from AI efficiency research or AI adoption. Instead, enterprises are learning from prior technology cycles, including the early evolution of cloud computing.That is a sensible comparison.
Cloud adoption did not eliminate the need for security investment. It forced organizations to rethink security architecture. Identity became more central. Network perimeters became less reliable. Logging, encryption, configuration management, and shared-responsibility models grew more important.
AI is likely to create a similar transition.
The false choice between speed and safety
Some organizations still frame security as a drag on AI deployment. That framing is outdated. Poorly secured AI implementations are likely to become a source of delay, rework, audit findings, employee distrust, and operational disruption.Security is not separate from AI value realization. It is one of the conditions for achieving it.
An AI system that cannot handle sensitive data safely will be restricted to low-value tasks. An agent that lacks reliable access controls cannot be trusted with meaningful workflow automation. A company that cannot explain what an agent did will struggle to use that agent in regulated, customer-facing, or high-impact processes.
This means security investment can increase the range of AI use cases that an organization can responsibly pursue.
Measuring AI return on investment
Patel’s caution that AI needs to demonstrate tangible returns is equally important. The infrastructure behind modern AI can be expensive. Costs may include model inference, GPU capacity, data preparation, integration work, governance tooling, security controls, training, and support.The most common trap is measuring success through activity rather than outcomes.
An enterprise may celebrate the number of employees with AI access, the number of agents created, or the volume of prompts submitted. Those metrics say little about whether the organization is producing value.
More useful measures include:
- Reduction in mean time to detect or respond to security incidents
- Reduction in repetitive service-desk work
- Faster remediation of known vulnerabilities
- Improved developer productivity with measurable quality controls
- Lower error rates in defined business workflows
- Faster knowledge retrieval without increased data exposure
- Reduced operational downtime
- Higher first-contact resolution rates
- Fewer manual steps in approved processes
- Better auditability and policy enforcement
The Economics of AI Efficiency Are Changing
AI infrastructure costs do not come only from training massive models. For most organizations, the more immediate challenge is inference: the cost and performance required to run models and agents reliably at scale.An agentic system can consume far more tokens and compute than a single user query. It may inspect documents, reason over a task, call tools, validate intermediate output, retry failed steps, invoke other agents, and maintain contextual state. Each of those activities contributes to latency and cost.
More autonomy can mean more compute
There is a tendency to describe AI agents as efficient digital workers. In some workflows, they can be. But an agent that takes multiple reasoning steps, checks several data sources, and revises its approach can be significantly more expensive than a simple assistant.This does not make agentic AI a bad investment. It means enterprises need realistic expectations.
AI leaders should distinguish between:
- Model capability: What the AI can theoretically do
- Workflow reliability: How consistently it completes the assigned task
- Operational cost: What each useful completed task actually costs
- Risk-adjusted value: Whether savings survive the cost of oversight, security, and exception handling
Right-size the model and the agent
The best AI architecture will rarely be “use the largest model for everything.” Enterprises should match capability to task.Smaller or specialized models may be appropriate for:
- Alert classification
- Ticket triage
- Log summarization
- Data extraction
- Policy tagging
- Routine code scanning
- Knowledge-base retrieval
- Language translation
- Standardized internal workflows
This is where the connection between AI efficiency and cybersecurity becomes especially strong. A well-designed system can reduce cost and risk at the same time. It can route routine tasks to smaller models, require approval for high-impact actions, use policy enforcement before tool execution, and maintain a complete audit trail.
Cisco’s New AI Security Tools and the Defensive AI Opportunity
Cisco has been expanding the use of AI for cybersecurity, including capabilities aimed at securing agentic workflows and finding software weaknesses faster. Its recent work on smaller AI models designed to investigate code repositories for known vulnerabilities highlights an important trend: security AI does not always need to be a general-purpose chatbot.Specialized models can be valuable because they are tuned for a defined security problem. In vulnerability management, the question is not merely whether a known CVE exists in theory. Teams need to understand whether the affected component is present, reachable, exploitable in context, and urgent enough to prioritize.
That is where AI-assisted code and repository analysis can help.
The promise of AI-assisted vulnerability management
Security teams often face an overwhelming number of alerts, findings, patches, and potential exposures. A focused AI system may help reduce the time spent on repetitive investigation by:- Mapping known vulnerabilities to internal code
- Identifying potentially affected dependencies
- Explaining why a finding may or may not be relevant
- Summarizing code paths for human review
- Prioritizing likely risk based on contextual evidence
- Suggesting remediation steps
- Creating drafts for tickets, reports, or engineering tasks
But the value depends on verification. A security AI tool should accelerate investigation, not become an unquestioned authority.
Automation must not become automatic trust
Security teams have long dealt with false positives, incomplete context, and noisy detections. AI does not eliminate those problems. It may alter their shape.An AI model can misinterpret code, overstate confidence, overlook environmental context, or produce a plausible but incorrect explanation. When the output is used to prioritize remediation, communicate risk, or approve an action, human review remains essential.
The strongest deployment pattern is usually human-led, AI-accelerated security operations:
- AI gathers and summarizes evidence
- AI identifies likely relationships and anomalies
- Analysts validate the conclusion
- Approval gates control consequential actions
- Automation executes only defined and reversible responses
- Every action is logged for review
China, Open Models, and the Global AI Competition
Patel’s recognition of China as a formidable AI competitor reflects a broader reality in the global AI market. The competition is no longer limited to who can train the largest closed model. It increasingly involves model efficiency, deployment flexibility, open-weight availability, developer ecosystems, hardware access, enterprise integration, and the speed at which capabilities spread.China’s AI ecosystem has demonstrated that innovation can come from architectural efficiency, training methods, engineering discipline, and open distribution—not only from matching the largest U.S. infrastructure investments dollar for dollar.
That has implications for enterprise buyers.
Open source versus open weights
The language around “open-source AI” can be misleading. Many models described as open are more accurately called open-weight models. Their weights may be downloadable and usable under a license, but the training data, training code, full methodology, or commercial rights may not be fully open.That distinction matters for governance, compliance, and security.
Organizations should not assume that an openly available model is automatically transparent, safe, auditable, or free of licensing constraints. They should evaluate:
- License terms and redistribution rights
- Commercial-use restrictions
- Data-handling implications
- Security update processes
- Model provenance
- Vendor or community support
- Known safety limitations
- Compatibility with internal controls
- Whether deployment can remain within approved infrastructure
Openness can improve resilience—but it does not remove risk
A strong open model ecosystem can reduce dependence on a small number of providers. It can support research, customization, regional deployment, independent evaluation, and broader developer participation. It may also give enterprises more options when proprietary model pricing, availability, policy changes, or data residency requirements become problematic.However, open availability also lowers barriers for malicious use. Security teams must be realistic about that tension.
The appropriate response is not simplistic. It is not “all AI should be closed,” nor is it “all models should be released without safeguards.” The better approach is risk-based.
Lower-risk models, tools, datasets, and defensive capabilities can often benefit from wider availability. More capable systems that materially increase cyber, biological, fraud, or autonomy-related risks may require stronger controls, staged access, or more limited release strategies.
For the United States, the strategic argument for open AI is compelling when it expands the adoption of trusted American technology, development tools, infrastructure, and standards. But that argument only succeeds if openness is paired with credible security practices, clear licensing, high-quality documentation, and a serious commitment to trustworthy deployment.
What Windows and Enterprise IT Teams Should Do Now
The AI security conversation can feel abstract until an agent is connected to business data, endpoint tools, and administrative workflows. At that point, the organization needs a practical operating model.Build an inventory before expanding use
Most enterprises have better visibility into laptops and servers than they do into AI applications, models, agents, prompts, connectors, and service accounts. That gap must close.Maintain an inventory that records:
- AI applications and agents in use
- Model providers and model versions
- Data sources and retrieval systems
- Agent owners and business sponsors
- Connected tools and APIs
- Identity and credential types
- Permitted actions
- Human approval requirements
- Logging and retention arrangements
- Third-party dependencies
- Deployment locations and data residency
Apply identity-first controls
Every agent should have a distinct identity. Shared administrator credentials, generic API tokens, and broad application permissions are especially dangerous in agentic environments.Use least privilege, short-lived tokens where possible, segmented access, strong authentication for sensitive operations, and explicit approval steps for elevated actions. Monitor agent behavior as closely as the behavior of privileged users and service accounts.
Keep high-impact actions behind approval gates
Not every workflow needs full autonomy. Organizations should classify actions according to consequence.Low-risk activities may be automated, such as drafting a summary, categorizing a ticket, or gathering diagnostic information. Moderate-risk activities may require review, such as creating a change request or generating a remediation script. High-risk activities should require explicit human approval, including account changes, policy modifications, production deployments, financial actions, destructive commands, or external data sharing.
This design preserves the productivity benefits of AI while preventing a single flawed reasoning chain from becoming a business-impacting event.
Test for adversarial behavior, not just usability
AI pilots often focus on whether a system gives helpful answers. Security testing should also ask whether the agent can be manipulated.Test scenarios should include:
- Malicious instructions in documents and webpages
- Attempts to access data outside the assigned scope
- Misleading tool descriptions
- Poisoned knowledge-base entries
- Sensitive-data extraction attempts
- Privilege escalation requests
- Unexpected multi-step behavior
- Repeated attempts to bypass policy
- Tool-call failures and retry loops
- Incorrect but confident security recommendations
The Bottom Line: AI Value Depends on Control
Cisco’s position captures a central truth of the current AI era: organizations do not need to choose between AI investment and cybersecurity investment. They need to make the two investments work together.AI agents may become powerful operational tools in security, IT administration, software development, customer support, and enterprise workflow automation. But that power comes from access—to data, systems, tools, and identities. The more useful the agent becomes, the more carefully it must be governed.
The same principle applies to the global AI race. Open models, efficient architectures, and broad developer ecosystems can accelerate innovation and strengthen competitiveness. Yet openness without security discipline can create new risks for enterprises and governments alike.
For Windows and enterprise IT teams, the practical path is not to delay AI indefinitely or to deploy agents without restraint. It is to build AI systems around least privilege, continuous verification, runtime visibility, measurable business value, and human accountability. The organizations that do so will be better positioned to capture AI’s benefits without turning their own infrastructure into the proving ground for the next generation of cyber threats.
References
- Primary source: startuphub.ai
Published: 2026-07-25T00:07:40.174000+00:00
Cisco on AI Security: Agents, Costs, and China | StartupHub.ai
Cisco's Jeetu Patel discusses AI agent security risks, the dual concerns of cybersecurity and token costs, and the US's need to invest in open-source AI.www.startuphub.ai - Related coverage: cisco.com
- Related coverage: newsroom.cisco.com
Cisco Redefines Security for the Agentic Era with AI Defense Expansion and AI-Aware SASE
Cisco (NASDAQ: CSCO) today announced a sweeping evolution of its security portfolio.newsroom.cisco.com - Related coverage: blogs.cisco.com
Cisco explores the expanding threat landscape of AI security for 2026 with its latest annual report - Cisco Blogs
Thank you to all of the contributors of the State of AI Security 2026, including Amy Chang, Tiffany Saade, Emile Antone, and the broader Cisco AI researchblogs.cisco.com - Related coverage: investor.cisco.com
Cisco Redefines Security for the Agentic Era with AI Defense Expansion and AI Aware SASE 2026
PDF documentinvestor.cisco.com
- Related coverage: techradar.com
Cisco tried using AI to write security incident reports — and things didn't really go as planned | TechRadar
There are many challenges with generating long-form reports with AI, Cisco foundwww.techradar.com