iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Not with blanket authority. An AI agent may use valid access to workplace tools in ways its owners did not intend if it is compromised or manipulated. Trust should therefore depend on the particular agent’s permissions, connected systems, permitted actions, oversight, and testing—not on the label “AI agent” or the model alone.
That is the central concern in The Cyber Express’s August 27, 2026 interview with Adarsh Kant Sinha, founder and CEO of ANVE.AI. The feature raises relevant security questions, but it is an interview summary, not an empirical study or an independent test of any named agent. Read the interview at The Cyber Express.
Why do AI agents create a different security question?
A conventional scripted workflow follows predefined steps. An agent, by contrast, may pursue a goal by choosing among actions or tools. The security implications depend on what it can actually do: an agent connected to email, chat, customer records, financial systems, or cloud infrastructure has a different risk profile from one that can only draft a response.
If an agent is manipulated or compromised, its legitimate access could be used for an unauthorized purpose. That is a risk scenario discussed in the interview, not a report of a measured incident rate. The practical issue is the combination of decision-making and authority: what the system can reach, what it can change, and whether a person can intervene before consequential actions occur.
#1 Best Overall
What does Sinha’s interview establish—and what doesn’t it?
The feature presents Sinha’s views on workplace access, governance, voice AI, red-teaming, prompt injection, and the distinction between copilots and agents. It quotes him saying, “Everyone wants AI agents,” and frames the adoption of agents as a reason to take security design seriously. The article does not report a detailed testing methodology, decision thresholds, named incident examples, or measured security results.
Accordingly, the interview is useful as a prompt for governance questions, not as evidence that a particular agent is safe or unsafe. Its biographical description of Sinha—including a claim that he has built a community of more than 25,000 ethical hackers—is the publisher’s characterization, not an independently verified security statistic.
What should an organization examine before granting authority?
Assess the whole system, not just the underlying model. The relevant boundary includes the agent’s identity and credentials, connected data and applications, integrations, tools, and actions it is allowed to take.
- Identity and credentials: Which identity does the agent use, and can each consequential action be attributed to it?
- Reach: Which systems and data can it access? Are those permissions limited to the task, or do they expose unrelated resources?
- Action scope: Can it read, draft, send, edit, approve, delete, transfer, or change configurations? Distinguish low-impact and reversible actions from actions with lasting or high-impact effects.
- Approval and intervention: Which actions require human approval? Can the reviewer see the relevant context, reject the action in time, and stop the agent when it behaves unexpectedly?
- Auditability: Are tool calls, decisions, approvals, and resulting changes recorded in a way that supports investigation and accountability?
- Testing: Has the organization evaluated manipulated inputs, prompt-injection attempts, insecure integrations, overbroad permissions, and failure or recovery paths?
“Human in the loop” is not a sufficient control by itself. A reviewer who sees too little context, has no realistic time to assess a request, or cannot block the action may provide little meaningful oversight.
How can NIST’s AI RMF help structure the decision?
NIST’s AI Risk Management Framework (AI RMF) offers a voluntary process for addressing risk through four functions: Govern, Map, Measure, and Manage. NIST describes it as a framework to improve the ability to incorporate trustworthiness considerations into AI design, development, use, and evaluation. It is not a certification that an agent is safe, and it does not replace system-specific security controls. NIST says AI RMF 1.0 is being revised. See NIST’s AI Risk Management Framework overview.
- Govern: Assign responsibility for agent permissions, approvals, monitoring, and incident response.
- Map: Document the agent’s purpose, users, connected systems, data, identities, and possible consequences of its actions.
- Measure: Evaluate whether controls work, including under manipulated inputs and integration failures; record what was tested and what remains uncertain.
- Manage: Reduce, transfer, avoid, or accept risks deliberately, then monitor the system as its tools, permissions, or use change.
NIST’s core guidance also calls for organizations to define and document human-oversight processes. The useful question is not simply whether oversight exists, but what a reviewer can see and do before an agent’s action takes effect.
Rank #4
Why identity and authorization deserve separate attention
NIST’s National Cybersecurity Center of Excellence published a concept paper on software-agent identity and authority on February 5, 2026. It describes a potential project and solicited public input; it is not a completed standard or a binding requirement. The paper identifies topics for consideration including identification, authorization, auditing, non-repudiation, and prompt-injection controls, reflecting the risks that arise when agents can reach data, tools, and applications. Read NIST NCCoE’s concept paper announcement.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For an organization, this makes identity design more than an administrative detail. If an agent’s actions cannot be distinguished from a shared human or service account, investigation and accountability become harder. Authorization should likewise be specific enough to limit the agent’s reach and actions to the job it is meant to perform.
Best Value
How should teams decide what an agent may do?
Match authority to the task and the consequence of failure. A system that drafts text can be treated differently from one that sends messages, changes records, approves payments, or modifies infrastructure. Use the following sequence before expanding its permissions:
- Inventory the job and connections. Name the task, required data, identity, tools, and integrations. Remove access that is not needed for that job.
- Separate suggestions from execution. Start with read-only access or drafts where feasible. Require explicit approval before actions that are difficult to reverse or could materially affect people, finances, or operations.
- Make approval meaningful. Show the reviewer the action, target, relevant context, and likely effect; allow enough time to assess it and provide a usable way to reject or stop it.
- Log actions and test boundaries. Preserve attributable records of agent activity and approvals, and test the system’s behavior with manipulated inputs, unexpected tool results, and integration failures.
- Review after changes. Reassess permissions, oversight, and tests when the agent gains new tools, data, users, or responsibilities.
These steps are a practical synthesis of the interview’s concerns and NIST’s risk-management and identity guidance, not a checklist quoted from Sinha.
When is trust justified?
Trust is conditional and specific: it should be earned for a defined task, within documented authority, with controls suited to the impact of failure. The more consequential or irreversible an action is, the stronger the case for narrow permissions, effective human approval, attributable logs, and testing of misuse and failure paths. A general claim that an agent is “enterprise-ready” or has a human reviewer does not establish those safeguards.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
