Why AI Agents Need Identity Governance

Enterprise AI is entering a dangerous phase.

Organizations are rapidly deploying AI agents that can:

• access enterprise systems,
• retrieve sensitive data,
• invoke APIs,
• execute workflows,
• make operational decisions,
• and even coordinate with other agents.

But there’s a problem.

Most enterprises are governing these AI agents using identity systems designed for:

• employees,
• web applications,
• and static service accounts.

That model is already breaking.

Recent research from the OpenID Foundation warns that traditional authentication and authorization frameworks are insufficient for autonomous AI agents operating across systems and organizational boundaries.  

The real issue isn’t just “AI security.”

It’s identity governance.

Because every AI agent is becoming a new kind of non-human identity.

---

The Shift Enterprises Are Underestimating

For years, identity governance focused primarily on humans:

• employees,
• contractors,
• partners,
• administrators.

Then came machine identities:

• service accounts,
• API tokens,
• bots,
• workloads,
• automation pipelines.

Now, agentic AI is creating a third category:

autonomous non-human actors capable of reasoning and taking action.

This changes everything.

Unlike traditional automation, AI agents:

• adapt dynamically,
• make probabilistic decisions,
• chain actions across systems,
• delegate tasks,
• and operate with partial autonomy.

That means the governance challenge is no longer static access management.

It becomes:

• continuous trust evaluation,
• behavioral governance,
• runtime authorization,
• and accountability.

The Cloud Security Alliance recently argued that organizations must treat AI agents as “first-class identity principals” subject to the same governance lifecycle as human accounts.  

That’s a foundational shift in enterprise architecture.

---

Why Traditional IAM Breaks Down

Traditional IAM assumes predictable behavior.

1. A user logs in.
2. A request is made.
3. Policies are evaluated.
4. Access is granted or denied.

AI agents don’t behave that way.

An AI agent may:

1. receive a high-level objective,
2. generate its own execution plan,
3. invoke multiple tools,
4. call external APIs,
5. retrieve sensitive data,
6. spawn sub-agents,
7. and continuously adapt its actions.

The problem is not authentication alone.

The problem is governance visibility.

Questions enterprises suddenly need to answer include:

• Who authorized the agent?
• What permissions were delegated?
• What actions were taken autonomously?
• Which downstream systems were affected?
• Can decisions be audited?
• Can actions be reversed?
• Who is accountable?

Most enterprises cannot answer those questions today.

And that’s becoming a major governance gap.

---

AI Agents Are Accelerating the Non-Human Identity Explosion

Security teams already struggle with machine identity sprawl.

Many enterprises now have vastly more non-human identities than human users.

Recent industry analysis estimates machine identities outnumber humans by ratios ranging from 45:1 to 82:1 in enterprise environments.  

AI agents dramatically accelerate that growth.

Every agent may create:

• API credentials,
• delegated OAuth scopes,
• ephemeral tokens,
• memory stores,
• runtime sessions,
• sub-agent chains,
• external integrations.

Without governance, enterprises lose visibility almost immediately.

This creates what many security leaders are now calling:

“The AI identity crisis.”

Recent research shows enterprises are adopting AI agents faster than they can govern or secure them.  

---

Identity Is Becoming the Control Plane for AI

For years, security teams focused on:

• network security,
• endpoint security,
• perimeter defense.

But AI agents don’t fit neatly into those models.

AI systems move across:

• APIs,
• cloud services,
• SaaS platforms,
• vector databases,
• orchestration frameworks,
• external tools,
• and agent-to-agent ecosystems.

Identity becomes the only consistent enforcement layer.

That’s why modern AI governance is increasingly identity-centric.

The emerging model is:

• authenticate every agent,
• authorize every action,
• validate every delegation,
• monitor every runtime behavior,
• audit every decision trail.

In practice, this means enterprises need:

• agent identity inventories,
• task-scoped permissions,
• ephemeral credentials,
• continuous behavioral monitoring,
• delegated authority controls,
• and runtime policy enforcement.

The old model of “assign static permissions and hope for the best” no longer works.

---

The Biggest Governance Risk: Delegated Authority

One of the most underestimated risks in agentic AI is the delegation of authority.

When humans use software directly, accountability is relatively straightforward.

But when humans delegate actions to AI agents, governance becomes much more complicated.

Consider this scenario:

A finance employee authorizes an AI agent to:

• generate procurement recommendations,
• negotiate pricing,
• and execute approved purchases.

Now ask:

• What are the approval boundaries?
• Can the agent exceed spending thresholds?
• Can it interact with external vendors?
• Can it negotiate autonomously?
• Can it trigger downstream workflows?
• What happens if it chains actions unexpectedly?

Traditional IAM systems were never designed for this level of dynamic delegation.

The OpenID Foundation explicitly warns that current identity standards struggle to handle complex permission sharing and autonomous delegation between agents.  

This is why AI governance increasingly requires:

• policy-bound delegation,
• verifiable authorization chains,
• runtime enforcement,
• and continuous trust validation.

---

Why Static Governance Is Failing

Most enterprise governance today is periodic.

Examples:

• quarterly access reviews,
• annual audits,
• static RBAC policies,
• manual entitlement reviews.

AI agents operate continuously.

Governance must therefore become continuous too.

Modern AI governance requires:

• runtime observability,
• behavioral analytics,
• decision traceability,
• live policy enforcement,
• anomaly detection,
• and dynamic authorization.

Recent security research argues that auditability and continuous observability are becoming baseline enterprise requirements for AI systems.  

This is a major architectural shift:

Governance is moving from static administration to runtime control.

---

The Rise of Agent-to-Agent Ecosystems

The challenge becomes even greater when agents begin interacting with one another.

Emerging protocols like Agent2Agent (A2A) aim to standardize communication between autonomous AI systems.  

That creates entirely new governance questions:

• How do agents establish trust?
• How is delegated authority verified?
• How are actions constrained?
• How do enterprises govern cross-domain interactions?
• How do you audit multi-agent workflows?

This begins to resemble distributed identity federation — but for autonomous systems.

Existing IAM models are not prepared for it.

---

What Enterprises Need Next

Enterprises don’t just need “AI governance policies.”

They need:

AI Identity Governance Architectures

That includes:

1. Agent Identity Lifecycle Management

Every AI agent should have:

• unique identity,
• ownership,
• lifecycle tracking,
• and revocation controls.

---

2. Least Privilege by Default

Agents should receive:

• task-scoped permissions,
• ephemeral access,
• just-in-time authorization,
• and bounded execution rights.

---

3. Runtime Authorization

Authorization decisions must become:

• contextual,
• dynamic,
• continuous,
• and risk-aware.

---

4. Behavioral Monitoring

Security teams need visibility into:

• tool usage,
• action chains,
• abnormal behavior,
• delegation patterns,
• and policy violations.

---

5. Human Accountability Layers

Humans remain responsible for:

• governance boundaries,
• escalation paths,
• high-risk approvals,
• and irreversible decisions.

AI autonomy cannot eliminate accountability.

---

The Future of Enterprise AI Governance

The next generation of enterprise AI security will not be built primarily around models.

It will be built around:

• identity,
• authorization,
• runtime governance,
• and trust orchestration.

The organizations that succeed with agentic AI will not simply deploy the smartest agents.

They will deploy:

• governable agents,
• observable agents,
• auditable agents,
• and controllable agents.

Once AI agents can take action independently, identity governance becomes mandatory.

It becomes the foundation of enterprise trust.

---

Final Thought

Most enterprises are still asking:

“What can AI agents do?”

The more important question is:

“Who governs what AI agents are allowed to do?”

That question will define the future of enterprise AI security.

---

Sources & Research

• OpenID Foundation AI Identity Management Whitepaper
• Cloud Security Alliance Research on AI Agent IAM
• Enterprise AI governance and runtime oversight research
• Academic research on Machine Identity Governance Taxonomy (MIGT)

Please feel free to comment your feedback and reachout me psrdotcom@gmail.com

Governance and security for autonomous AI agents

Hi all,

Over the next few weeks, I’ll be publishing a deep-dive series on one of the most overlooked challenges in enterprise AI:

Governance and security for autonomous AI agents.

Most conversations around AI are still focused on:

• model performance,
• copilots,
• automation,
• and productivity.

But a much bigger shift is happening underneath:

AI agents are becoming autonomous digital actors inside enterprise environments.

They can:

• access systems,
• invoke APIs,
• make decisions,
• execute workflows,
• and interact with other agents.

Which raises entirely new questions around:

• identity,
• authorization,
• runtime security,
• accountability,
• Zero Trust,
• and governance.

This series will explore topics like:
→ Why AI Agents Need Identity Governance
→ Non-Human Identity Security for Agentic AI
→ AI Governance Is the New Zero Trust
→ Why Traditional AppSec Fails for AI Agents
→ Human-in-the-loop Governance for Enterprise AI
→ The Future of AI Authorization
→ AI Runtime Security vs Traditional Security
→ Can AI Ever Be Truly Explainable?

My goal is simple:
Cut through the AI hype and focus on the architectural, governance, and security realities enterprises will soon face.

Because the next major cybersecurity challenge may not be human users.

It may be autonomous AI identities operating at machine speed.

Starting tomorrow with:

“Why AI Agents Need Identity Governance”

#AI #AgenticAI #AISecurity #IdentityGovernance #ZeroTrust #EnterpriseAI #CyberSecurity #IAM #NonHumanIdentity #AIGovernance

Feel free to comment and reach out to me at psrdotcom@gmail.com

Authenticating with Jira Cloud APIs to Create and Fetch Issues

🚀 End-to-End Guide: Authenticating with Jira Cloud APIs to Create and Fetch Issues

Integrating with Jira Cloud programmatically is a common requirement for automation, testing, and DevOps workflows. This guide walks through the complete authentication flow using OAuth (client credentials) and demonstrates how to fetch and create Jira issues using REST APIs.

This approach is designed for non-interactive service integrations, meaning no UI login is required.

---

🔐 Overview of the Flow

At a high level, interacting with Jira APIs involves four key steps:

1. Generate an access token
2. Discover accessible resources (Cloud ID)
3. Fetch existing issues
4. Create new issues

Each step builds on the previous one.

---

1️⃣ Generate an Access Token

Authentication begins by exchanging your client credentials for an access token.

Pre-requisites

1. Create a service user in Atlassian Jira directory.
2. Create an OAuth 2.0 credentials to get the Client ID and Client Credentials.

Request

POST https://auth.atlassian.com/oauth/token
Content-Type: application/json

Body

{
  "grant_type": "client_credentials",
  "client_id": "{{CLIENT_ID}}",
  "client_secret": "{{CLIENT_SECRET}}",
  "audience": "api.atlassian.com"
}

This returns a response containing:

{
  "access_token": "your_token_here",
  "expires_in": 3600
}

You’ll use this access_token for all subsequent API calls.  

---

2️⃣ Retrieve Cloud ID (Accessible Resources)

Jira APIs require a Cloud ID, which identifies the Jira instance associated with your token.

Request

GET https://api.atlassian.com/oauth/token/accessible-resources
Authorization: Bearer {{ACCESS_TOKEN}}
Accept: application/json

Response

[
  {
    "id": "cloud-id",
    "url": "https://your-instance.atlassian.net"
  }
]

• id → used as cloudId
• url → base Jira site URL

This step is essential because all Jira API calls must go through the API gateway using the Cloud ID.  

---

3️⃣ Fetch a Jira Issue

Once authenticated, you can retrieve issue details.

Request

GET https://api.atlassian.com/ex/jira/{{CLOUD_ID}}/rest/api/3/issue/{{PROJECT_KEY}}-1
Authorization: Bearer {{ACCESS_TOKEN}}
Accept: application/json

What this does

• Uses the API gateway (api.atlassian.com)
• Authenticates with Bearer token
• Fetches a specific issue using its key

This endpoint returns full issue details including summary, status, and metadata.  

---

4️⃣ Create a Jira Issue

Creating issues programmatically is one of the most common use cases.

Request

POST https://api.atlassian.com/ex/jira/{{CLOUD_ID}}/rest/api/3/issue
Authorization: Bearer {{ACCESS_TOKEN}}
Accept: application/json
Content-Type: application/json

Body

{
  "fields": {
    "project": {
      "key": "{{PROJECT_KEY}}"
    },
    "summary": "Bug created from API",
    "description": {
      "type": "doc",
      "version": 1,
      "content": [
        {
          "type": "paragraph",
          "content": [
            {
              "type": "text",
              "text": "Created via API using OAuth token"
            }
          ]
        }
      ]
    },
    "issuetype": {
      "name": "Bug"
    }
  }
}

Important Notes

• Description must use Atlassian Document Format (ADF) — plain text is not accepted.
• project.key must exist in your Jira instance.
• issuetype.name must be valid (e.g., Bug, Task, Story).

This request creates a new issue and returns its ID and key.  

---

🔁 Automating the Flow

In tools like Bruno or Postman, you can automate this workflow:

• Store access_token after token request
• Extract cloudId dynamically
• Reuse both in subsequent requests

Example script:

const body = bru.response.json();
bru.setEnvVar("ACCESS_TOKEN", body.access_token);

---

⚠️ Common Pitfalls

❌ Using the wrong base URL

• Don’t use: https://your-domain.atlassian.net/rest/api/...
• Use: https://api.atlassian.com/ex/jira/{cloudId}/...

---

❌ Missing permissions

• The service account must have:
  • Browse Projects
  • Create Issues (for POST)

---

❌ Invalid payload

• Missing required fields → 400 error
• Wrong issue type → validation failure

---

❌ Expired token

• Tokens expire (usually in 1 hour)
• Regenerate as needed

---

🧩 Putting It All Together

Here’s the complete sequence:

1. 🔑 Get access token
2. 🌐 Get Cloud ID
3. 📥 Fetch issue
4. 📤 Create issue

This workflow enables full read/write automation with Jira Cloud APIs.

---

🏁 Conclusion

Using OAuth with client credentials provides a secure and scalable way to interact with Jira Cloud APIs without relying on user login or UI access.

With just a few API calls, you can:

• integrate Jira into CI/CD pipelines
• automate bug creation
• build dashboards or monitoring tools

Once set up, this becomes a powerful foundation for any Jira-based automation.

---

Please feel free to reachout psrdotcom@gmail.com for any feedback and suggestions.

Making a Local Dev Server accessible via Public Domain using Cloudflare Tunnel

Hi all,

Today, we are going to discuss how you can publicly access the local running server with a domain and Cloudflare tunnel.

Pre-requisites

1. Domain
2. DNS on Cloudflare
3. Cloudflare One account access
4. Local server

Set up the environment

Application

Make sure your application runs locally on a port like 8000,9000 etc.

Cloudflare Tunnel

1. Log in to your Cloudflare One account.
2. Go to "Zero Trust".
3. Expand Networks and select Connectors.
4. Click on “Create a tunnel”.
5. Select “Cloudflared”.
6. Give a name to your tunnel.
7. Click on “Save”.
8. In the "Choose your environment" section, select the environment where the server is running.
9. Follow the instructions to install and run a connector.
10. Here, you need to move to your server machine.
11. Open the terminal and perform the instructions to install the "cloudflared" tool.
12. Run using the token (part of the command).
13. Once the installation is completed. Click on Save.

Add IP/CIDR

1. Edit the tunnel to add the IP/CIDR.
2. Choose based on your local DHCP.

Published application routes

1. Click on “Add a published application route”.
2. Give an optional subdomain.
3. Select the domain from the dropdown.
1. You need to have your domain managed by Cloudflare (DNS).
4. An optional path to make sure you have a frontend and a backend that work together.
5. Under service, select Type as HTTP, and your local machine server port.
6. Select the URL of the server application, including the localport.
1. localhost:9000
7. Click on “Save”.

Note: If you have a frontend and a backend, then you need to add one more application route.

In my scenario, the frontend path is * with localhost:9001, and the backend path is api/* with localhost:8000.

Run the tunnel

1. Make sure your local web server is running
2. Log in to cloudflared

• cloudflared tunnel login

• Authorize the tunnel on the web browser post login
3. List the tunnels

• cloudflared tunnel list

4. Get the tunnel token from the tunnel you created in Cloudflare connectors
5. Run the command on the local terminal

• cloudflared tunnel run --token eyJhIjoiM2...

6. Now, you should be able to browse your configured subdomain with your local web server content. 

Troubleshooted issue

If the frontend with path "/*" is above the backend route, then your backend APIs will never be reached.

So, "move up" the backend with "/api/*" path above the frontend to serve the requests.

Feel free to reach out to me if you have any doubts and clarifications needed at my email psrdotcom@gmail.com

Migrate from Nginx to Caddy for SSL auto-renewal in Amazon AWS EC2

 Dear friends,

Today, we will see a simple migration with less configuration of SSL auto-renewal.

I was using Nginx for SSL auto-renewal using certbot. Every 90 days, the renewal code should run, I made one more service it.

I have come across Caddy, which does an auto-renewal of SSL automatically with certbot. Reducing efforts and making the system smooth.

Follow the steps below

Stop and disable the Nginx

sudo systemctl stop nginx

sudo systemctl disable nginx

Install the Caddy

In EC2, if you are running Amazon Linux, then execute the following to install Caddy.

    sudo yum -y install yum-plugin-copr

    sudo yum -y copr enable @caddy/caddy epel-8-$(arch)

    sudo yum -y install caddy

Edit and configure the Caddyfile

Usually, it will be in the path /etc/caddy/Caddyfile

sudo vi /etc/caddy/Caddyfile

I have only one server that is running locally. So, my configuration is easy

domain_name {

    reverse_proxy localhost:port

}

You can configure more with your existing Nginx sites-enabled reference.

Happy SSLing.

If you like the blog or want to comment, kindly reach out to psrdotcom@gmail.com

Indian Passport renewal process and documents

 Hi all,

Here is the updated process for renewing a passport for an adult and a child on the same day and time.

Appointment

• Visit the India Passport Seva website
• Click on "Register" if you don't have an account.
• Click on "Login" if you already have an account.
• After successful login, navigate to "Services".
• 
• Click on "Fresh Passport/Re-Issue of Passport"
• Enter your existing passport number to pre-fill the data.
• If it's a fresh passport or you want to manually enter the details, click on the "Skip for Now" link.
• Choose the Passport Office
• You should see the form below 
• 
• In the case of "Re-issue of Passport", you will have options to change/modify details in existing passport.
• 
• Check the appropriate items
• When you check the "Change in Existing Personal Particulars", you will have options to update the following details.
• 
• After selecting the "Type of Application" and "Type of Passport Booklet"
• Click on "Save and Next".
• Post that you will be navigated tothe  next section as mentioned in the flow below.
• 
• Fill in the relevant details and submit the form.
• After submitting the form, you will be able to upload the relevant documents that are available in the DigiLocker.
• Select the center and date that you want to visit.
• Note: It did not help me to smooth the process even after uploading the documents.

Visiting Center

• Take all hard copies, Originals, and Xerox (2 sets)
• Application form
• Aadhaar Card (Full length)
• Existing passport (Front 2 and back 2 Pages) Xerox (no print out with 100% page fill)
• In case of a spouse's addition 
• Marriage certificate original
• For the kid application
• Fill in "Annexure D"
• Date of Birth Certificate
• Counters
• A Counter: Verification of the documents, scanning the documents, and taking a photo.
• B Counter: Cross verification of the A counter form and documents.
• C Counter: Originals will be verified.

Police Verification (Will be indicated in the status of the application after the center visit)

• In a couple of days, the police will call and make sure you are available upon the visit at the address submitted in the passport application.
• Submitted the application form that has been finalized during the center visit.
• Original documents (Old passport(s) and address proof).
• Details of the neighbour's & physical presence with a signature.
• Applicant's signature and thumb along with a passport-size photo that will be stuck to the police filled application.

Please provide your feedback and comments on this blog or email me on psrdotcom@gmail.com

Create static website using ChatGPT Website Generator Plugin

Hi Everyone,

Here we are where ChatGPT is gathering the required services under one roof.

Click on "Explore GPTs"

Search for "Website Generator"

Prompt the website with the name and major product/service offerings.

It will redirect to the B12 domain with a template. You can update each section with the B12 editor.

For reference, you can visit my website https://psr-and-apps.b12sites.com/index#home

Feel free to send your comments and opinions to psrdotcom@gmail.com