DEV Community: Securis360 Inc.

What Security Leaders Need to Know About AI Agent Permissions

Securis360 Inc. — Wed, 07 Oct 2026 13:46:31 +0000

For years, enterprise security teams have been comfortable thinking about access in terms of people, devices and applications.

An employee logs in. A service account connects to an application. An administrator receives privileged access. Policies determine what each identity can see and do.

AI agents are changing that model.

Unlike traditional software, an AI agent can interpret a goal, decide which tools it needs, access information, call APIs and take actions across multiple systems. The agent may be operating on behalf of a person, but it can make decisions and execute steps at a speed and scale that are difficult for humans to supervise manually.

That creates an important question for security leaders:

What exactly should an AI agent be allowed to do?

The answer cannot simply be "whatever the user can do."

NIST's recent work on software and AI agent identity and authorization highlights the need to address agent identification, authentication, authorization, auditing, delegation and human authorization as distinct security concerns. NIST

For security leaders, this means treating AI-agent permissions as an enterprise identity and governance problem, not simply an AI implementation detail.

AI Agents Are Becoming Enterprise Identities

One of the easiest mistakes is to treat an AI agent as just another application feature.

That becomes problematic when the agent can interact with enterprise resources.

An agent might:

• Read customer records
• Search internal documents
• Access email or calendars
• Query databases
• Create or modify tickets
• Call external APIs
• Write code
• Deploy applications
• Trigger business workflows
• Make decisions on behalf of users

At that point, the agent is no longer simply producing an answer. It is operating within an environment of permissions.

ISC2 has described this as one of the important challenges of agentic AI: agents blur the boundary between technical assets and digital identities because they interact with files, databases and collaboration platforms in ways that resemble human users. ISC2

Security leaders therefore need to ask a basic question for every deployed agent:

Does this agent have its own identity, or is it borrowing someone else's?

Borrowing human credentials creates an accountability problem. If an agent uses an employee's credentials, it becomes much harder to determine whether a particular action was performed directly by the employee, automatically by the agent, or because the agent interpreted a request differently than expected.

NIST has specifically warned about credential sharing and recommends treating agents as first-class entities with unique identifiers, credentials and associated entitlements. NIST
Least Privilege Still Matters, But the Model Has to Change
Least privilege is not a new security concept.

The principle is straightforward: an identity should receive only the minimum access necessary to perform its function. NIST Computer Security Resource Center

The challenge with AI agents is that their behavior can be more dynamic than traditional software.

A conventional application may have a relatively predictable set of operations. An AI agent may receive a high-level objective and determine which tools, data sources and APIs it needs along the way.
That makes broad permissions particularly dangerous.

Imagine an agent that has access to:

• A CRM
• Internal files
• Email
• A financial system
• Customer information
• Software repositories

The agent may technically need access to several of these systems, but it should not automatically receive unrestricted access to everything simply because the user who initiated the task has that access.

NIST's current agent identity work specifically raises the question of how organizations can establish least privilege when an agent's required actions may not be completely predictable at deployment time.

For security leaders, this points toward a more granular model.

Instead of asking:

"What can this agent access?"
Ask:
"What does this agent need to do right now, and what is the minimum authority required to accomplish that task?"

Authorization Should Become More Contextual

Traditional authorization often happens around a relatively simple decision:

Identity + role + resource = access decision
Agentic systems introduce additional context.

For example:
• Who initiated the task?
• What is the agent trying to accomplish?
• Which tool is it attempting to use?
• What data will the action expose?
• Is the action read-only or does it change something?
• Is the action inside the user's original intent?
• Is the requested privilege appropriate for the current task?
• Does the action cross a security or organizational boundary?

NIST's September 2026 summary of feedback on agent identity and authorization found strong support for more dynamic, context-aware authorization. The feedback also highlighted concerns about agents accumulating permissions as tasks are chained across multiple agents and systems. NIST Pages

This is where Zero Trust principles become particularly relevant.

Instead of authorizing an agent once and trusting it throughout an entire workflow, organizations can move toward continuous evaluation of authorization at the point where an action is requested.

That does not necessarily mean building an entirely new security architecture.

It means applying existing identity and access principles more dynamically.

Human Approval Still Has a Role

There is understandable pressure to make AI agents completely autonomous.

But autonomy should not automatically mean unrestricted authority.

Some actions carry substantially more risk than others.

Reading a public document is very different from:

• Deleting production data
• Transferring money
• Changing access permissions
• Deploying production code
• Sending sensitive information externally
• Modifying security controls

Security leaders should identify actions where human approval remains appropriate.

The goal is not to put a human in the middle of every agent action. That would eliminate much of the value of automation.

Instead, organizations can establish risk-based approval thresholds.
Low-risk actions can be automated.

Medium-risk actions can require additional policy checks.

High-impact actions can require explicit human authorization.

This approach allows organizations to maintain automation while preserving accountability for consequential decisions.

Permissions Need to Follow the Task
Another important consideration is delegated authority.
An agent may be acting on behalf of a user. That does not mean it should inherit every permission available to that user.

The authority granted to the agent should be constrained by the purpose of the task.

For example, if an employee asks an agent to prepare a sales report, the agent might need permission to read specific CRM records and reporting data.

It should not automatically receive permission to:

• Delete customer records
• Change billing information
• Modify user accounts
• Export the entire customer database

The difference is subtle but important.

User authority and agent authority should not necessarily be identical.
NIST's recent agentic AI work refers to this concept through delegated rights, task-scoped authorization and authorization attenuation, where downstream agents receive narrower permissions than the authority from which they were delegated. NIST Pages

Security Leaders Also Need Better Visibility
Permissions are only useful when organizations know what has been granted.
As enterprises deploy more agents, security teams will need visibility into:

• Which agents exist
• Who owns them
• What identities they use
• Which systems they can access
• Which tools they can call
• What permissions they currently have
• Who authorized those permissions
• How often permissions are used
• What actions the agents perform
• When permissions should expire

This becomes especially important because AI agents may be created dynamically or exist only for a limited period.

NIST's recent analysis of stakeholder feedback notes that the scale and potentially ephemeral nature of agents can create significant challenges around issuing, managing and auditing identities and credentials. NIST Pages

For security teams, this suggests that an AI-agent inventory should eventually become part of normal identity governance.

Logging Should Capture More Than the Login

Traditional security logs often answer questions such as:

Who logged in?
For AI agents, that is not enough.

Security teams increasingly need to understand:
• Which agent acted?
• On whose behalf?
• What task was it performing?
• Which tool did it use?
• What information did it access?
• What authorization allowed the action?
• What did the agent actually do?
• Was human approval involved?
• Did the agent deviate from the expected workflow?

This level of visibility becomes particularly important when investigating incidents.

If an agent makes an unexpected change, security teams need enough evidence to reconstruct the decision and authorization chain.

NIST's agent identity work explicitly identifies auditing and non-repudiation as areas requiring attention, including the ability to connect agent actions back to human authorization. NCCoE

Prompt Security Is Not a Substitute for Access Control

Another important distinction is between controlling what an AI model is instructed to do and controlling what it is technically allowed to do.

Prompt instructions might tell an agent:
"Only access customer information necessary for this task."
But that instruction should not be the only security control.

If the underlying identity has unrestricted access to a database, a prompt does not create a reliable authorization boundary.

Technical permissions should enforce the boundary.

This becomes particularly important in the presence of prompt injection and other attacks that attempt to influence agent behavior. NIST's agent identity project specifically considers prompt injection alongside identification, authorization and auditing because these controls need to work together. NCCoE

A secure architecture therefore assumes that an agent's instructions can sometimes be manipulated and ensures that technical authorization controls limit the resulting impact.

A Practical Checklist for Security Leaders

Organizations preparing for broader AI-agent adoption can start with a relatively straightforward set of questions:

Inventory the agents
Identify which AI agents are already operating across the organization, including agents introduced by business teams.
Give agents distinct identities
Avoid shared human credentials wherever possible. Establish accountability for agent actions.
Map permissions
Document which applications, APIs, data sources and tools each agent can access.
Reduce standing privileges
Use short-lived or task-specific authorization where practical instead of permanent broad access.
Separate read and write capabilities
An agent that needs to read information may not need permission to modify it.
Define high-risk actions
Determine which actions require additional controls or human approval.
Monitor agent behavior
Compare what an agent actually does with what it was expected to do.
Build rapid revocation
If an agent behaves unexpectedly or its credentials are compromised, security teams need a fast way to disable its authority.
Connect agent activity to existing security operations
Agent identities, authorization events and anomalous behavior should be visible to the teams responsible for detection and response.
Review permissions regularly
Agent permissions should not become permanent simply because they were appropriate when the agent was first deployed.

The Bigger Shift: From User-Centric IAM to Human and Machine Authority
AI agents are not eliminating the principles that have governed identity and access management for decades.

They are exposing where those principles need to become more granular.
Security leaders should continue to rely on established foundations such as unique identity, authentication, authorization, least privilege, separation of duties, monitoring and accountability.

But those controls need to accommodate a new type of actor: software that can interpret instructions, interact with multiple systems and take autonomous actions.

The most important question is therefore not whether organizations should allow AI agents to operate.

The question is how much authority they should receive, under what conditions, and how quickly that authority can be changed or revoked.

The organizations that answer those questions early will be in a stronger position to scale agentic AI without allowing automation to quietly become a new source of excessive privilege.

AI agents may be autonomous, but their authority should never be undefined.

Top Cloud Security Risks Businesses Must Avoid

Securis360 Inc. — Mon, 21 Sep 2026 05:19:43 +0000

Cloud computing has changed how businesses build, operate, and scale their technology environments. Applications, databases, employee collaboration tools, customer platforms, analytics systems, and even security operations increasingly run across cloud infrastructure.

But moving workloads to the cloud does not automatically make them secure.

In fact, cloud environments can introduce new security challenges because organizations are managing identities, permissions, APIs, storage, workloads, applications, third-party integrations, and configurations across increasingly distributed environments. Microsoft identifies misconfigurations, excessive permissions, compromised credentials, insecure APIs, insider risks, shadow IT, and multicloud complexity among the common causes of cloud data exposure.

AWS similarly organizes cloud security around security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security.

For businesses, the challenge is therefore not simply moving to the cloud. It is maintaining security as the cloud environment changes.

Here are some of the most important cloud security risks businesses should avoid.

1. Cloud Misconfigurations

One of the most common cloud security problems is incorrect configuration.

Cloud platforms provide powerful controls for networking, storage, identity, applications, databases, and security. But those controls still need to be configured correctly.

*Examples include:
*

Publicly accessible storage
Overly permissive firewall rules
Open management interfaces
Incorrect IAM policies
Unrestricted network access
Exposed databases
Unprotected secrets
Incorrect security group configurations

Microsoft identifies cloud configuration errors such as unsecured storage, overly permissive IAM policies, and exposed management consoles as common cloud security risks.

The challenge becomes greater when infrastructure is deployed rapidly or automatically.

Infrastructure as Code can improve consistency, but a security mistake in a reusable template can also be replicated across multiple environments.

How to reduce the risk

Businesses should:

Continuously assess cloud configurations
Use secure configuration baselines
Automate configuration checks
Review internet-facing resources
Scan Infrastructure as Code before deployment
Remediate critical findings quickly

2. Excessive User Permissions

Cloud environments can contain hundreds or thousands of identities.

Employees, administrators, developers, applications, service accounts, contractors, and third-party systems may all require some level of access.

The problem begins when users receive more permissions than they actually need.

For example, an employee who only needs to read a database may receive permission to modify or delete it.

Over time, permissions can accumulate and create unnecessary exposure.

Microsoft recommends managing the identity and access lifecycle so permissions remain aligned with business requirements and are removed when they are no longer needed.

How to reduce the risk

Implement:

Least-privilege access
Role-based access control
Regular access reviews
Just-in-time privileged access
Strong authentication
Automated employee offboarding
Separate administrative accounts

AWS also recommends establishing a strong identity foundation and applying least privilege when managing cloud access.

3. Compromised Cloud Credentials

A stolen password can become an entry point into a cloud environment.

Attackers may obtain credentials through:

Phishing
Malware
Credential theft
Password reuse
Exposed secrets
Social engineering
Compromised third-party services

Cloud credentials can be particularly sensitive because they may provide access to applications, data, infrastructure, or administrative functions.

Microsoft notes that weak, stolen, or compromised credentials can lead to unauthorized access and data exposure.

How to reduce the risk

Businesses should consider:

Phishing-resistant MFA
Strong identity controls
Privileged access management
Credential rotation
Secrets management
Conditional access
Continuous authentication monitoring
Detection of suspicious login activity

4. Poor Data Protection

Businesses move valuable information into cloud environments:

Customer data
Financial records
Intellectual property
Employee information
Healthcare information
Business documents
Source code
Authentication information

If this data is not properly protected, a cloud security incident can become a significant business problem.

Cloud data security should cover the complete lifecycle of information, including storage, access, transmission, processing, backup, and deletion.

AWS identifies data protection as one of the core areas of cloud security.

How to reduce the risk

Organizations should implement:

Data classification
Encryption at rest
Encryption in transit
Strong access controls
Data loss prevention
Secure backups
Key management
Data retention policies
Regular access reviews

5. Insecure APIs

Modern cloud applications depend heavily on APIs.

Applications use APIs to communicate with:

Databases
SaaS platforms
Mobile applications
Cloud services
Payment systems
Internal applications
Third-party platforms

An insecure API can expose sensitive information or provide an attacker with an unauthorized path into an application or cloud environment.

Microsoft specifically identifies insecure APIs and third-party integrations as potential pathways for data exposure and compromise.

How to reduce the risk

Businesses should implement:

Strong API authentication
Authorization controls
Input validation
Rate limiting
API inventory
API security testing
Logging and monitoring
Secrets management

APIs should also be included in penetration testing and application security assessments.

6. Exposed Cloud Storage

Cloud storage is one of the areas where a small configuration mistake can create significant exposure.

A storage resource that is unintentionally public can potentially expose sensitive business information to unauthorized users.

This can include:

Documents
Customer records
Backup files
Logs
Application data
Media files
Internal reports

Microsoft specifically cites misconfigured storage resources as a cause of cloud data exposure.

How to reduce the risk

Organizations should:

Identify all cloud storage resources.
Determine which data they contain.
Review public-access settings.
Apply least-privilege policies.
Encrypt sensitive information.
Monitor access continuously.
Alert on unexpected exposure.

7. Lack of Cloud Security Monitoring

Deploying security controls without monitoring them creates another problem.

A business may have:

IAM
Firewalls
Endpoint protection
Cloud security tools
Encryption
Security policies

But if nobody is monitoring security events, suspicious activity can go unnoticed.

AWS includes detection and incident response among its core cloud security practices.

Cloud monitoring should provide visibility into:

Authentication events
Privileged activity
Configuration changes
Network activity
API calls
Data access
Suspicious workloads
Security alerts

The objective is to identify unusual activity early enough for security teams to investigate.

8. Ignoring Vulnerabilities in Cloud Workloads

Cloud infrastructure still contains:

Virtual machines
Containers
Operating systems
Applications
Libraries
Databases
Network services

These components can contain vulnerabilities.

Microsoft's cloud security recommendations include critical vulnerabilities that can enable remote code execution, privilege escalation, or system takeover.

How to reduce the risk

Businesses should maintain:

Asset inventories
Vulnerability scanning
Patch management
Container security
Dependency scanning
Configuration assessment
Regular penetration testing

Security testing should cover both infrastructure and applications.

9. Third-Party and SaaS Risk

Cloud environments rarely consist of one provider.

Businesses often connect multiple:

SaaS platforms
Cloud providers
APIs
MSPs
Vendors
Consultants
Business applications

Each connection can introduce another security dependency.

A security weakness at a third-party provider can potentially affect your organization.

Microsoft identifies third-party integrations as an additional pathway for cloud data exposure.

How to reduce the risk

Organizations should:

Maintain a third-party inventory
Assess vendor security
Review integrations
Limit third-party permissions
Monitor vendor access
Include cybersecurity requirements in contracts
Regularly review vendor relationships

10. Shadow IT

Employees sometimes adopt applications or cloud services without going through formal IT or security processes.

This can create shadow IT.

Examples include:

Unapproved SaaS applications
Personal cloud storage
Unmanaged collaboration tools
Browser-based AI services
Personal file-sharing platforms
Unsanctioned development environments

The security team may not know what data is being stored or who has access to it.

Microsoft identifies shadow IT and unmanaged applications as sources of security blind spots.

How to reduce the risk

Businesses should establish:

SaaS discovery
Application inventories
Approved application policies
Data classification
Identity-based access controls
Employee security awareness
Cloud access monitoring

11. Weak Cloud Incident Response

Even strong security programs can experience incidents.

The question is how quickly and effectively the organization can respond.

A cloud incident response plan should address:

Who receives alerts?
Who investigates?
Who can disable compromised accounts?
Who can isolate workloads?
Who communicates with customers?
Who manages regulatory obligations?
How are cloud logs preserved?
How are credentials revoked?
How is the environment recovered?

AWS lists incident response as a core cloud security practice and recommends having a well-defined and practiced process.

A response plan that exists only in a document is not enough.

Organizations should periodically test it.

12. Multicloud Complexity

Many organizations use more than one cloud provider.

For example:

AWS + Azure + Google Cloud + SaaS

Each platform can have different:

Identity systems
Security controls
Logging mechanisms
Network architectures
Configuration models
Compliance requirements

Microsoft notes that hybrid and multicloud environments can make it harder to consistently enforce security and access policies.

How to reduce the risk

Businesses should establish common security standards across environments.

For example:

Centralized identity governance
Consistent access policies
Unified monitoring
Common vulnerability management
Standard security baselines
Centralized incident response
Regular cloud security assessments
13. Not Understanding the Shared Responsibility Model

One of the most important concepts in cloud security is the shared responsibility model.

Cloud providers secure the infrastructure they operate, but customers still have responsibilities for the security of their own data, applications, identities, configurations, and workloads, depending on the service being used.

AWS explicitly distinguishes between security of the cloud and security in the cloud. Customer responsibilities vary according to the service and other factors such as data sensitivity and applicable requirements.

In simple terms:

Moving something to the cloud does not transfer all security responsibility to the cloud provider.

Businesses need to clearly understand what the provider secures and what they remain responsible for.

14. Poor Cloud Security Governance

Technology alone cannot solve every cloud security problem.

Organizations also need governance.

That includes:

Security policies
Access governance
Data governance
Configuration standards
Risk management
Compliance requirements
Security ownership
Audit processes
Incident response procedures

Without governance, cloud environments can become inconsistent as different teams deploy resources independently.

A Practical Cloud Security Checklist

Businesses can use this checklist as a starting point:

Identity

MFA enabled
Privileged accounts protected
Least privilege implemented
Access regularly reviewed
Former employee access removed

Infrastructure

Cloud configurations regularly assessed
Internet-facing assets identified
Security groups reviewed
Vulnerabilities scanned
Workloads patched

Data

Sensitive data classified
Encryption enabled
Storage permissions reviewed
Backups protected
Data access monitored

Applications

APIs inventoried
APIs security tested
Secrets protected
Dependencies monitored
Application vulnerabilities assessed

Monitoring

Cloud logs collected
Security events monitored
Privileged activity tracked
Suspicious behavior detected
Alerts investigated

Third Parties

Vendors assessed
SaaS applications inventoried
Third-party permissions reviewed
Integrations monitored
Vendor access removed when no longer required

Incident Response

Cloud incident response plan documented
Security contacts identified
Credential revocation process defined
Backup recovery tested
Incident response exercises conducted

*Final Thoughts
*
Cloud security is not a one-time configuration exercise.

Cloud environments change continuously. New users are added, applications are deployed, APIs are connected, permissions change, workloads move, and third-party services are introduced.

That means cloud security needs to be continuous.

The most important areas for businesses to address include:

Misconfiguration

Identity and access

Data protection

API security

Vulnerability management

Cloud monitoring

Third-party risk

Incident response

Multicloud governance

Shared responsibility

AWS's current Well-Architected security guidance similarly organizes cloud security around identity and access management, detection, infrastructure protection, data protection, incident response, and application security.

The goal is not simply to make the cloud environment harder to attack.

It is to build an environment where organizations can identify risk, prevent unnecessary exposure, detect suspicious activity, respond quickly, and maintain control over their data and systems.