Why Agent Authorization Differs from User Permissions – The AEGIVELA Security Model

Traditional Identity and Access Management (IAM) answers two questions: who the user is and whether the user may access a system. Agent systems break this model because an agent may be launched by a user, continue running in the background, receive delegation from another agent, invoke tools, inject temporary credentials, and hand off parts of its workload to other executors. In such a chain, knowing only the original login does not prove that the current action remains authorized.

AEGIVELA is an identity, authorization, and security infrastructure designed for agent environments. It decomposes the security process into seven distinct components.

1. Distinguish Human, Agent, and Workload Identities

Human identities are sourced from the enterprise IdP, workloads have their own Workload Identity, and each agent requires an independent binding record. Collapsing these three into a shared service account would prevent determination of who issued a request, which agent made a decision, and which workload performed the action.

2. Separate Policy Decision from Execution

The Policy Decision Point evaluates subject, resource, action, environment, and risk level to produce a structured decision. The evaluation follows a fail‑closed posture: if policy, identity, or environmental information is insufficient, the request is denied rather than automatically allowed for availability.

3. Approvals Must Have Explicit Scope

Approvals that merely state “approve agent operation” are not valid corporate approvals. Approval artifacts must bind to specific resources, actions, scopes, and expiration times, and be signed to prevent tampering.

4. Delegation Must Not Amplify Privileges

If an upstream agent only has read permission, it cannot create write permission when delegating downstream. Any budget, time, or resource constraints imposed upstream are inherited or further tightened downstream.

5. Execution Uses Short‑Term Grants

AEGIVELA issues audience‑bound, short‑lived Ed25519 JWS Execution Grants. The execution system validates the grant’s signature, audience, scope, and validity period, eliminating the need for agents to retain long‑term high‑privilege credentials.

6. Revocation Is a First‑Class Capability

Enterprises can revoke based on tenant, subject, session, policy, approval, or execution grant, allowing immediate response to risk without waiting for short‑term credentials to expire naturally.

7. Security Facts Must Form Evidence

Each authorization decision, approval, and execution can emit de‑identified, SIEM‑compatible JSON evidence, linked across systems via correlation identifiers. AEGIVELA also supports artifact attestation, verifying binaries with digests, signer identity, and runtime evidence, ensuring that granting a capability does not automatically allow any version of code to run.

The model embodies a key shift in agent security: permissions should not be permanently attached to an agent; they should be issued at the moment of action, be minimal, short‑lived, audience‑bound, and revocable.

The open‑source repository includes versioned JSON Schema, OpenAPI, Protobuf contracts, a Go SDK, API‑protection examples, and multi‑platform binaries.

Project URL: https://github.com/axisrobo/aegivela-open