Cisco MyAgent: Permission Design at Company-Wide Scale
An AI agent available to every employee—Cisco's announcement asks where you draw permission boundaries, before it asks how capable the model is.
On August 27, 2026, Cisco announced on its official blog that it is rolling out an AI agent called MyAgent to approximately 90,000 employees. The post was written by Thimaya Subaiya, EVP of Operations at Cisco.
What stands out is not the launch of another tool for a specialist team, but the decision to make MyAgent available across Cisco’s workforce. Cisco says MyAgent was built for all Cisco employees and delivers a personalized experience by retaining each user’s preferences, past interactions, and context. Drawing on an exclusive interview with Subaiya, The Wall Street Journal reports that each agent is designed for an individual employee and accepts requests only from the person it supports.
MyAgent runs on Circuit, the internal AI platform Cisco has been building. Cisco describes Circuit as a secure, governed, model-agnostic AI platform, and says MyAgent works across business applications such as Outlook, Webex, Jira, and SharePoint. An employee provides a goal, context, and a desired outcome, and MyAgent determines the sequence of steps needed to complete the task. Cisco frames this as a move from chat-based interaction toward supervised autonomous workflows.
What Cisco Disclosed
The following points come directly from Cisco’s own blog post.
- Persistent memory: Cisco says the agent has persistent memory that retains users’ preferences, past interactions, and context over time. The design carries context across interactions and workflows.
- Restricted access: Cisco states explicitly that MyAgent only accesses approved models, approved systems, and enterprise-appropriate data pathways. It does not reach everything; it operates inside a pre-authorized boundary.
- Human role and accountability: According to Cisco, employees continue to set intent, apply judgment, and remain accountable for outcomes, while AI helps improve speed, efficiency, and focus.
- Growth in usage volume: Cisco says agentic interactions on Circuit grew nearly 350% quarter over quarter. What grew is the volume of interactions. Cisco does not publish absolute numbers, user counts, or the amount of work completed.
What The Wall Street Journal Reported
Some widely quoted details about this rollout do not appear in Cisco’s blog post. They come from The Wall Street Journal’s article based on an exclusive interview with Subaiya. That is not a primary document Cisco published on its own site, but it is also not an unsourced secondhand account—it is reporting drawn from a direct interview with the executive responsible. We treat it separately from Cisco’s own statements.
The Journal reports that more than 800 sub-agents operate behind the scenes; that each agent accepts requests only from the employee it supports; that any external action requires that employee’s explicit approval; that a policy server blocks operations such as deleting datasets; and that enterprise information is retrieved through secure corporate connectors based on each user’s existing access permissions.
The same article also reports figures on how requests are distributed for cost reasons. Because the definitions behind those categories and the denominator are not published, we leave them aside in an article about permission design.
What This Announcement Marks
It is worth noting that this is not the first time AI reached company-wide scale at Cisco. In a separate blog post published on July 27, 2026, Cisco said Circuit had passed 100,000 users and reached 90% employee adoption.
What this announcement marks, then, is not the first company-wide use of AI at Cisco. It marks the evolution of an already widely used AI platform from model access and answer support toward supervised execution across multiple business systems.
Company-Wide Rollout and the Need for Consistent Access Controls
Each individual capability in MyAgent—turning a goal into a sequence of steps, retaining memory, working across applications—has become fairly common over the past year or two. What makes this announcement notable, in our view, is the scope of the rollout rather than the capabilities themselves.
The difference between a small pilot and a rollout targeting 90,000 people is the scale at which the same controls must remain effective. A single gap in a shared policy or connector configuration can affect a large number of users with different roles, permissions, and work contexts. Managing those differences, detecting anomalies, and revoking access when necessary all become more complex as the rollout expands.
At this scale, the first question is not how cleverly an agent can assemble a sequence of steps. It is how to maintain consistent permission controls, approval requirements, monitoring, and revocation mechanisms across a large and varied user base.
Our View: What to Decide Before Scaling
We have long held that whether an AI deployment succeeds is not determined by model capability alone. It also depends on the design of the surrounding business system: how far the AI handles the work, where a person makes the decision, and who is ultimately accountable for the result.
Once an agent begins planning and executing steps toward a goal, the issue becomes more concrete: how should its permissions be scoped?
The distinction we care about most here is between assistance—having the agent propose what to do next—and execution. Asking an agent to suggest the next step and allowing it to execute that step involve materially different levels of risk.
Two distinct controls are visible in what Cisco has published. One is limiting the models, systems, and data pathways the agent can reach. The other is keeping intent and judgment with a person and running the workflow under supervision. The first answers, “What can the agent access?” The second answers, “Which actions may proceed autonomously, and where is human judgment or approval required?” These controls should be designed separately rather than treated as one.
Cisco’s blog post does not say at which point approval is required for individual operations. The Wall Street Journal, drawing on its interview with Subaiya, reports that any external action requires the assigned employee’s explicit approval.
The second principle we emphasize is setting explicit limits on the agent’s authority. That means deciding not only what systems and information the agent can access, but also which operations it can perform, what limits apply to amounts or transaction volume, how long it may operate without intervention, and how its access can be revoked and reassessed. The point is to decide these in advance.
This is not a new concept. It resembles what an organization already does when hiring someone: defining the scope of the role, spending authority, reporting lines, record-keeping requirements, and how access will be removed after a transfer or departure. The controls organizations have long applied to human roles and access rights need equivalents for AI agents.
That said, an agent repeats operations at machine speed and can connect to many systems by paths a person would not take, so simply porting human-oriented access management is not sufficient on its own.
We use an internal system in which AI handles part of our own article production. AI produces a draft, but a person reviews it and moves it forward, and nothing leaves the company without that second step. Ours is a small organization, but the underlying principle—not leaving both the proposal and the decision to act on it to the same party—applies at any scale.
A Practical Permission Inventory
You cannot lift MyAgent’s design into your own company as-is. But organizations of any size can inventory, dimension by dimension, the access and authority they have given an agent.
The table below is one example. It does not determine whether a setup is safe; it is a starting point for reviewing your own operations, controls, and risk tolerance. Where you draw a limit or a boundary is a decision each company must make based on its industry, its size, and the nature of the information it handles.
The way each control is implemented and enforced also varies. For each item, ask whether it can be enforced through a product setting or whether it must also be governed through an internal policy or process.
| Permission dimension | Cisco example (publicly disclosed) | Question to ask about your own setup |
|---|---|---|
| Target systems | Limited to approved systems such as Outlook, Webex, Jira, and SharePoint | Can the accountable owner identify every system the agent is allowed to access? |
| Information access | Only “enterprise-appropriate data pathways” | Have you explicitly identified data the agent must not access, such as customer records or HR data? |
| Permitted operations | ”Supervised autonomous workflows” that determine and carry out the steps | Have you distinguished between actions that should remain recommendations and those the agent may execute? |
| Operations requiring approval | The blog states human oversight. The Wall Street Journal reports that external actions require the assigned employee’s explicit approval | Which operations run automatically, and which require approval in advance? |
| Memory and context | Preferences, past interactions, and context retained over time | What gets remembered, and who can view, correct, or delete it? How is it handled on transfer or departure? |
| Logging and monitoring | Not disclosed in the MyAgent blog post | Can you trace who initiated or approved each action and what the agent executed, and stop the agent when anomalous activity is detected? |
| Autonomous runtime | Not disclosed in the MyAgent blog post | Is there a limit on how long, or over how many operations, it can run without human approval? |
| Revocation and review | Not disclosed in the MyAgent blog post | Following a role change, departure, or detected anomaly, can the agent’s access be revoked immediately? |
The MyAgent blog post does not disclose details of logging and monitoring, autonomous runtime, revocation and review, or memory-management policies such as retention, deletion, handling on a role change, and separation between users. That is also a limit of this article: even for a large-company deployment, outside observers cannot see the full permission design.
When you take your own inventory, those are the dimensions we would put first rather than last.
Cisco itself points in the same direction in separate published material. Its blog post of March 23, 2026, “Zero Trust for Agentic AI: Safeguarding your Digital Workforce,” calls for mapping each agent to a human owner, applying least privilege to the operations an agent can perform and not only the services it can reach, using identity-aware credentials with a limited lifetime, and monitoring continuously. It gives the example of an agent that can pay only approved vendors, within set amounts, and during the right hours.
That material describes Cisco’s general approach to agent security, however. It is not evidence that MyAgent implements all of it.
A Practical Caveat: Model Capability Is Not a Permission Boundary
One might reasonably ask whether a more capable model would simply avoid overstepping in the first place.
A more capable model may well make fewer errors and follow instructions more precisely. But model capability is not itself a permission boundary. As long as unnecessary access rights are granted, those rights remain, even if the model does not ordinarily exercise them.
The Cisco material cited above makes a related point: enforcement should not depend on an agent’s cooperation, and agents interact with tools and resources in unpredictable ways in the course of completing their tasks.
Rather than relying on model behavior alone to prevent consequential actions, we believe the surrounding system should constrain what the agent can access, which operations it can perform, the applicable amount and volume limits, the valid time window, and the conditions under which approval is required.
This article is limited to permission design for an AI agent assigned to an individual employee. Return on investment and how employees respond to the rollout are outside the scope of this article.
Closing Thoughts
What stands out in Cisco’s announcement is not the novelty of the functionality, but the attempt to maintain a clear design principle—keeping each agent within an approved boundary—at company-wide scale.
A company-wide rollout raises a specific question: how do you manage permissions that differ from user to user using a shared set of policies, approvals, monitoring, and revocation mechanisms?
Before scaling, it is worth inventorying the authority given to an agent across several dimensions: target systems, information access, permitted operations, approval requirements, logging, runtime, and revocation.
Starting with narrow permissions is far less costly than tightening them after deployment has already expanded.
Sources and Verification
This article was prepared using information available as of September 2026. Its primary source is Cisco’s August 27, 2026 blog post, “MyAgent and the Rise of Ambient Intelligence: Cisco’s Next Step in Enterprise AI,” written by Thimaya Subaiya, Executive Vice President, Operations.
For information on Circuit adoption, we referred to Cisco’s July 27, 2026 blog post, “From AI Experiments to 90% Adoption: How Cisco Operationalized AI at Scale.” For Cisco’s broader approach to agent permission controls, we referred to its March 23, 2026 post, “Zero Trust for Agentic AI: Safeguarding your Digital Workforce.”
The claims that MyAgent uses more than 800 sub-agents, requires explicit approval for external actions, uses a policy server to block operations such as deleting datasets, and accepts requests only from the employee it supports do not appear in Cisco’s own MyAgent blog post. We attribute these details to The Wall Street Journal’s reporting based on an exclusive interview with Subaiya and distinguish them from Cisco’s first-party disclosures.
Cisco’s post describes the rollout plan and certain publicly disclosed aspects of MyAgent’s design. It is not an independent assessment of the system’s safety or deployment results. The post does not report actual usage rates, task success rates, error rates, or return on investment.
MyAgent’s permission design and operating status may change.
The analysis and permission inventory in this article reflect MIF’s interpretation of publicly available information. They do not constitute a complete account of MyAgent’s specifications.