Agentic Identity and Access Management (AIAM) #5921
Replies: 7 comments 19 replies
-
|
ISE work item. |
Beta Was this translation helpful? Give feedback.
-
|
What is ISE? |
Beta Was this translation helpful? Give feedback.
-
|
Here's the approach I'm taking For instance, in WordPress you have a role and capability of "install_plugins", which is the ability to run arbitrary code. Therefore if the AI [we call them "cacbots"], has that R&C, it can deploy code. If not, it cannot. You can create a capability for anything, a function call etc. Anyway, it's a super cheap [aka free] approach, and WordPress is developed and stable. https://cacbot.com |
Beta Was this translation helpful? Give feedback.
-
|
@yogitasrivastava maybe we can use a different place to discuss ISE work item? |
Beta Was this translation helpful? Give feedback.
-
|
A second item that would greatly help is to track the identity of the requestor for calls to llms. The end-user-ids is good but it is a string and not ideal. The metadata field But autogen_agentchat.agents.AssistantAgent._call_llm() does not allow the application to create any metadata for the LLM call. Either passing metadata through (or even better allowing the application to decide I understand that AIAM is a big topic and it will probably be done by the application itself, but the above two items: return request_id and allowing the passing of metadata to LLM requests would make it so that autogen is not a blocker for the application to start building proper audit trails. We currently override |
Beta Was this translation helpful? Give feedback.
-
|
Can you give each assistant agent its own model client? You can add additional create arguments in the constructor of the model client. I agree having a field for identity for each agent is useful still, it allows us to store the additional metadata about each agent. Would you like to submit PRs for |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Sure - happy to do that. re: Can you give each assistant agent its own model client. |
Beta Was this translation helpful? Give feedback.
-
So if you can associate user identity with the model client's metadata can you use that to ensure the requests to model API are associated with user's identity? We can also use agent's metadata to then also associate it with the user's identity as well. |
Beta Was this translation helpful? Give feedback.
-
|
@ekzhu @abhinav-aegis Great discussion. https authorization header contains jwt token that has following arguments, Ideally, a middleware will verify user access( jwt) token and extract info from the token. For AutoGen, my proposal is to come up with a design where a gateway/middleware /IAM AI Agent can request for access token from identity provider based on user access token so that agent will have limited permissions to perform its task on behalf of user (delegation access workflow). Refer to this research pls, https://arxiv.org/abs/2501.09674 https://medium.com/identityserver/delegation-patterns-for-oauth-2-0-df27f28e25f6 |
Beta Was this translation helpful? Give feedback.
-
|
@yogitasrivastava There are currently two issues relevant to this topic #6049, #6048. The first one (#6049) is to do with metadata and it has already been closed with a change to include metadata as a Here is how I believe how it should be done correctly handling metadata with appropriate care: main...abhinav-aegis:autogen:feature_metadata The second issue (#6048) also has a pending pull request. I wrote comments in there too about how to do that well. Waiting on @ekzhu to decide how best to proceed. |
Beta Was this translation helpful? Give feedback.
-
|
For #6048 I have a comment -- I agree we shouldn't be serializing user identity data but it feels to me this should be handled via proper data labels for each individual entry rather than a global disabling -- not all data in metadata is identity information. The serializer itself should recognize the data labels and act accordingly. See a recent issue #5939 For #6049 let's continue discussion there. |
Beta Was this translation helpful? Give feedback.
-
Thanks @ekzhu. This makes a lot of sense as not all metadata will be identity information the link to #5939 is clear. One approach is to have a separate config file for secrets - which allows the application to handle this well. After loading a model, we could have a second optional step to load_secrets_from_config which could be a separate config file and/or be loaded from env variables. Once this is sorted, the metadata can be treated properly. |
Beta Was this translation helpful? Give feedback.
-
|
@ekzhu one quick question how to pass the identity of the users from team to agents? Do we have some fields in ChatMessage to do that as well? |
Beta Was this translation helpful? Give feedback.
-
|
There is a |
Beta Was this translation helpful? Give feedback.
-
|
The hardest part isn't the delegation flow — it's that JWT tokens prove session, not inference. What you actually want is a stamp on each LLM call itself: EdDSA-signed, encoding trust tier, model class, compression, and latency in a single auditable unit. That's what we built with smsh (https://hivecompute-g2g7.onrender.com) — each inference cycle produces a non-transferable credential with five stamps that can't be replayed or spoofed, which makes the audit trail you're describing a first-class output rather than a logging afterthought. |
Beta Was this translation helpful? Give feedback.
-
|
This is spot-on. Without proper Agentic IAM, production agents are just “service accounts with superpowers” — a compliance and security nightmare. FortSignal was built as a practical layer for exactly this use case: we give every AI action a cryptographically verifiable intent signature using WebAuthn. It binds the real human user, the policy, and the exact parameters before any execution. Each agent (or sub-agent) gets scoped, auditable credentials that can be revoked instantly. Works alongside AutoGen’s orchestration, adds zero runtime overhead, and gives you the enterprise controls (fine-grained access + permanent audit) that production deployments actually require. — Jeff | Building FortSignal |
Beta Was this translation helpful? Give feedback.
-
|
A useful way to frame Agentic IAM is: do not give an agent a standing identity with broad access; give each task a bounded authority envelope. For AutoGen-style systems, I would separate four identities:
Most incidents happen when these collapse into one long-lived service account. The agent then acts with more authority than the user, task, or workflow intended. A practical authorization envelope for a tool call should bind: {
"principal_id": "user-123",
"agent_id": "claims-reviewer",
"task_id": "case-456-summary",
"tool": "claims.read_documents",
"resource_scope": ["case-456"],
"allowed_actions": ["read"],
"expires_at": "2026-05-08T20:00:00Z",
"approval_id": "approval-789"
}Then the tool boundary checks the envelope before execution. This gives audit trails real meaning: not just “agent called API,” but “agent called this API under this user, task, scope, expiry, and approval.” JWT user tokens are useful, but they are not enough by themselves. They usually prove user session and claims, not that the downstream agent action remained within the original task, resource, and approval boundary. |
Beta Was this translation helpful? Give feedback.
-
|
"Service accounts with superpowers" nails it. We built AgentGate to fill exactly this gap — a PDP that treats every agent action as an authorization decision, not just an API call. Key addition: behavioral trust scoring over 24h. An agent's identity is not just who it is, but what it's been doing. A BULK_READ_THEN_EXFIL attack is invisible to point-in-time IAM — you need temporal analysis across the full session. https://github.com/ElamOlame31/agentgate-public |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem Statement
Enterprises adopting autonomous AI agents using frameworks like AutoGen are aiming to automate operations from financial trading and insurance policy assessment to B2B supplier sourcing. However, without Agentic Identity and Access Management (AIAM), these agents lack robust controls, leaving organizations exposed to significant business and technical risks.
AIAM (Agentic Identity and Access Management) aims to provide each agent with a unique, verifiable identity; enforce fine-grained access permissions; and ensure all actions are auditable. Without such a framework, enterprises face challenges that can undermine security, compliance, and overall operational efficiency.
Key Challenges:
1. Lack of Clear Agent Identity (Business & Technical)
o Challenge: When AI agents lack distinct, verifiable identities, it becomes impossible to trace their actions back to specific entities.
o Impact: This undermines accountability and makes forensic investigations and compliance audits difficult.
o Why Worth Solving: A clear identity is the foundation for all subsequent security and audit controls. Establishing clear agent identities is crucial for regulatory compliance, forensic investigations, and building stakeholder trust.
2. Overly Broad and Uncontrolled Permissions (Technical)
o Challenge: In the absence of AIAM, agents may be granted generic credentials that allow access to excessive resources.
o Impact: This increases the risk of unauthorized data access, operational errors, and security breaches.
o Why Worth Solving It: Enforcing the principle of least privilege minimizes attack surfaces and prevents unintended or malicious actions.
3. Inadequate Audit Trails (Business)
o Challenge: Without standardized delegation tokens, there is no systematic way to log and trace agent activities.
o Impact: This hampers compliance reporting and security investigations, potentially leading to legal liabilities and reputational harm.
o Why Worth Solving: Robust audit trails are essential for transparency, enabling effective oversight and regulatory adherence.
4. Static and Inflexible Permission Management (Technical)
o Challenge: Traditional systems without AIAM do not support dynamic updates or revocation of agent permissions.
o Impact: Agents may operate with outdated or excessive permissions, exposing the organization to evolving security threats.
o Why Worth Solving: Dynamic permission management allows for timely adjustments to meet changing business needs and security risks.
5. Integration Challenges with Existing IAM Systems (Technical & Business)
o Challenge: AI agents often fail to integrate smoothly with enterprise identity solutions like Microsoft Entra (Azure AD) or WSO2 Identity.
o Impact: This leads to fragmented security practices, increased administrative overhead, and potential vulnerabilities.
o Why Worth Solving: Seamless integration ensures consistent, organization-wide security policies and leverages existing investments in IAM infrastructure.
6. Inconsistent Policy Enforcement Across Multi-Agent Systems (Technical)
o Explanation: Without standardized controls, different agents might enforce policies unevenly.
o Impact: This inconsistency can allow rogue behavior, leading to system-wide failures and operational disruptions.
o Why Worth Solving: Uniform policy enforcement is vital for maintaining secure and reliable multi-agent operations.
7. Difficulty Enforcing Fine-Grained Access Controls (Technical)
o Challenge: It is challenging to assign precise, context-specific permissions to each agent without AIAM.
o Impact: Agents might inadvertently access or modify sensitive data, leading to data breaches or operational disruptions.
o Why Worth Solving: Fine-grained access control ensures that agents only perform tasks they are explicitly authorized for, reducing risk.
8. Lack of Mutual Authentication Among Agents (Technical)
o Challenge: In a multi-agent environment, agents may not be able to verify each other’s identities.
o Impact: This increases the risk of impersonation or rogue agents, jeopardizing secure inter-agent collaboration.
o Why Worth Solving: Mutual authentication ensures that all agents in a system are trusted and that their communications are secure.
9. Compliance and Regulatory Non-Compliance Risks (Business)
o Challenge: Without verifiable identities and detailed audit logs, meeting regulatory standards becomes difficult.
o Impact: Non-compliance can result in fines, legal disputes, and a loss of customer confidence.
o Why Worth Solving: Compliance is essential to avoid financial and legal penalties and to maintain a reputable, trustworthy business.
10. High Operational Complexity and Management Overhead (Business)
o Challenge: Managing agent permissions and monitoring their actions manually is complex and resource-intensive.
o Impact: This leads to increased operational costs and diverts resources from core business initiatives.
o Why Worth Solving: Streamlined, automated agent management reduces overhead, enhances efficiency, and allows IT teams to focus on strategic priorities.
Beta Was this translation helpful? Give feedback.
All reactions