How Permissions Work Under the Hood

We've seen that Apono adds and removes permissions automatically, but a common question is: what happens when an engineer makes multiple access requests to different resources? Does Apono create a new credential for each request? Is there a different role for each one?

The answer is no, and understanding how Apono manages this internally is important to avoid incorrect expectations about the security model.

The Role Is Single, the Permissions Are Dynamic

When Apono is integrated with an AWS account, it does not create a new IAM role for each access request. Instead, it works with a single PermissionSet (or a single IAM role) per user in each AWS account.

What changes with each request are the permissions assigned to that role. Each access request results in adding a specific inline policy for the requested resource. When the access expires, only that inline policy is removed — the others remain active until their own timers expire.

In practice, this means:

• At 10:00 AM, the engineer requests access to EC2 i-0abc123 for 4 hours. Apono adds an ssm:StartSession inline policy for that instance.
• At 11:30 AM, they request access to EC2 i-0def456 for 4 hours. Apono adds another inline policy to the same role.
• At 12:00 PM, they request access to the production database for 1 hour (via IAM Auth). Another inline policy, this time with rds-db:connect.
• At 1:00 PM, the database policy expires and is removed. The other two remain active.
• At 2:00 PM, the first EC2 policy expires and is removed. The second one continues.
• At 3:30 PM, the last policy expires. The engineer's role has no additional permissions.

Each request has its own lifecycle: approval, granting, timer, and revocation are independent. But they all operate on the same IAM identity.

Apono is a tool designed for organizations with a significant volume of users and resources — its cost is justified in companies where manual access control has become impractical. Apono works with both traditional IAM (IAM users and roles in a single account) and AWS IAM Identity Center in multi-account environments. In traditional IAM scenarios, the connector manipulates inline policies directly on the engineer's IAM users or roles. With Identity Center, it works with PermissionSets. Both models follow the same principle described in this article: one identity per user with dynamic permissions. However, for organizations with multiple AWS accounts, Identity Center is strongly recommended as the identity foundation before adopting Apono.

Why This Matters

Understanding this model prevents three common misconceptions:

1. "Each request creates a different credential"

No. The engineer continues using the same IAM role (or PermissionSet in the case of AWS IAM Identity Center). What changes are the policies attached to that role. In practice, the engineer doesn't need to switch credentials, re-login, or change AWS profiles with each request. They simply gain (and lose) permissions transparently.

2. "If I have two active accesses, one can interfere with the other"

No. The policies are independent and isolated by resource. Revoking one request removes only the policy for that specific request. If the engineer has simultaneous access to three EC2 instances, the expiration of access to one of them does not affect the other two.

3. "The role accumulates permissions forever"

It depends. Each policy is linked to an Access Flow, and it's the Access Flow that defines the expiration time. In most cases, the timer expires and the connector removes the policy automatically. However, an Access Flow can be configured with indefinite duration, meaning once granted, the access remains active until it is manually revoked by an administrator. In that scenario, yes, the permission accumulates on the role as long as no one revokes it. We'll cover expiration and revocation settings in detail when we discuss Access Flows.

What About Databases?

For databases with IAM authentication (PostgreSQL and MySQL on RDS/Aurora), the model is identical to what's described above: the rds-db:connect policy is added to and removed from the user's same IAM role.

For databases with native authentication (username and password), the single identity principle also applies. On the first access request to a database instance, Apono creates a user on the instance whose name is based on the engineer's email in Apono, with an automatically generated password. On subsequent requests to the same instance, the user already exists — Apono just adds or removes grants as requested.

Since an RDS instance can host multiple databases, the engineer can request access to different databases on the same instance at different times. Each request adds specific grants to the same user, and each has its own expiration:

• At 10:00 AM, the engineer requests access to the customers database. The connector creates the user (if it doesn't exist yet) and adds GRANT SELECT on the customers database tables.
• At 11:00 AM, they request access to the orders database on the same instance. The connector adds GRANT SELECT on the orders database tables to the same user, with the same password.
• At 11:00 AM, access to the customers database expires. The connector revokes only the grants for that database. Access to the orders database remains active.

Each request has its independent lifecycle, but they all operate on the same user on the instance — just as in IAM, where they all operate on the same role.

Model Summary

Aspect	IAM (role/PermissionSet)	Database (native)
User identity	Single per AWS account	One per request (temporary user)
What changes per request	Policies on existing role	New user on the database
Credential the engineer uses	Always the same (SSO/role)	Different each time
Independence between requests	Yes (isolated policies)	Yes (isolated users)
Risk of permanent accumulation	None (timer per policy)	None (DROP USER on timer)

Apono doesn't multiply identities. On AWS, it works with the role the engineer already has and dynamically adjusts what that role can do. For databases with native authentication, it creates temporary identities out of necessity, but each has a short lifespan and is automatically removed. In both cases, no permission survives beyond the approved timeframe.