[GH-ISSUE #138] Add Service Reference cache control flags

kerem commented

2026-03-07 19:42:14 +03:00

Owner

Originally created by @C85297 on GitHub (Feb 4, 2026).
Original GitHub issue: https://github.com/awslabs/iam-policy-autopilot/issues/138

I'd like to suggest a way for users to control the behaviour of the service reference cache.

Currently, the service reference cache is stored in the OS temp directory, under a IAMPolicyAutopilot directory, and expires after 6 hours.

I would suggest the addition of command line flags which could be used to specify an alternative directory, and override the cache expiry.

One use case which this would benefit is when running the command in a docker image. Allowing the user to control the cache directory will enable the user to point it to a volume to ensure the cache can be reused across containers.

It would also benefit those running IAM policy autopilot without internet access or with restrictive firewalls, who could disable the cache expiry.

As an alternative to command line flags, environment variables could be used. Perhaps these would make more sense, particularly in the context of managed environments or docker images.

Additionally, functionality could be added to fallback to an expired cache, with a warning, if internet access is not available.

And yet another option would be just to bundle the service reference into the binary, as is currently done for botocore data. This seems less ideal, but it would remove a lot of complexity, avoiding the need to make web requests and maintain a cache at runtime.

Let me know your thoughts - it depends a lot on the direction you have planned for the project. I'd be happy to implement this feature and make a pull request in whichever way you prefer.

Originally created by @C85297 on GitHub (Feb 4, 2026). Original GitHub issue: https://github.com/awslabs/iam-policy-autopilot/issues/138 I'd like to suggest a way for users to control the behaviour of the service reference cache. Currently, the service reference cache is stored in the OS temp directory, under a `IAMPolicyAutopilot` directory, and expires after 6 hours. I would suggest the addition of command line flags which could be used to specify an alternative directory, and override the cache expiry. One use case which this would benefit is when running the command in a docker image. Allowing the user to control the cache directory will enable the user to point it to a volume to ensure the cache can be reused across containers. It would also benefit those running IAM policy autopilot without internet access or with restrictive firewalls, who could disable the cache expiry. As an alternative to command line flags, environment variables could be used. Perhaps these would make more sense, particularly in the context of managed environments or docker images. Additionally, functionality could be added to fallback to an expired cache, with a warning, if internet access is not available. And yet another option would be just to bundle the service reference into the binary, as is currently done for botocore data. This seems less ideal, but it would remove a lot of complexity, avoiding the need to make web requests and maintain a cache at runtime. Let me know your thoughts - it depends a lot on the direction you have planned for the project. I'd be happy to implement this feature and make a pull request in whichever way you prefer.

kerem added the

enhancement

label

2026-03-07 19:42:14 +03:00

kerem commented

2026-03-15 11:49:56 +03:00

Author

Owner

@weibenz1 commented on GitHub (Feb 4, 2026):

Hey @C85297 , thanks for the issue.

This is something we talked about that this is the exact data point that we were looking for before jumping in into the implementation.

The caching logic has two parts:

In-memory cache for long standing MCP processes
file based cache for standalone cli runs.

And yet another option would be just to bundle the service reference into the binary, as is currently done for botocore data. This seems less ideal, but it would remove a lot of complexity, avoiding the need to make web requests and maintain a cache at runtime.

I'd vote against it - the update in service reference changes on daily basis. If we build it into binary, we'd lose accuracy - e.g. new action new being picked up as part of static analysis/policy generation.

override the cache expiry.

FWIW, you can already disable cache - https://github.com/awslabs/iam-policy-autopilot/blob/main/iam-policy-autopilot-cli/src/main.rs#L308-L314. By default, the file-system based cache is enabled for standalone CLI runs, and disabled for running it as a mcp.

For the override of location, I'm all in for that - and support for cmd line + env variable make sense! What do you think?

@weibenz1 commented on GitHub (Feb 4, 2026): Hey @C85297 , thanks for the issue. This is something we talked about that this is the exact data point that we were looking for before jumping in into the implementation. The caching logic has two parts: 1. In-memory cache for long standing MCP processes 2. file based cache for standalone cli runs. > And yet another option would be just to bundle the service reference into the binary, as is currently done for botocore data. This seems less ideal, but it would remove a lot of complexity, avoiding the need to make web requests and maintain a cache at runtime. I'd vote against it - the update in service reference changes on daily basis. If we build it into binary, we'd lose accuracy - e.g. new action new being picked up as part of static analysis/policy generation. >> override the cache expiry. FWIW, you can already disable cache - https://github.com/awslabs/iam-policy-autopilot/blob/main/iam-policy-autopilot-cli/src/main.rs#L308-L314. By default, the file-system based cache is enabled for standalone CLI runs, and disabled for running it as a mcp. For the override of location, I'm all in for that - and support for cmd line + env variable make sense! What do you think?

kerem commented

2026-03-15 11:50:02 +03:00

Author

Owner

@C85297 commented on GitHub (Feb 5, 2026):

@weibenz1 Yep I agree with your thoughts there - so perhaps we could have three flags available from command line and environment variables:

disable_cache - already exists (but can add an environment variable source)
cache_expiry - -1 = never expires, 0 = cache disabled, >0 = number of ms
cache_location

Let me know if those sound good to you and I could go ahead and make a merge request.

@C85297 commented on GitHub (Feb 5, 2026): @weibenz1 Yep I agree with your thoughts there - so perhaps we could have three flags available from command line and environment variables: 1. `disable_cache` - already exists (but can add an environment variable source) 2. `cache_expiry` - `-1` = never expires, `0` = cache disabled, `>0` = number of ms 3. `cache_location` Let me know if those sound good to you and I could go ahead and make a merge request.

kerem commented

2026-03-15 11:50:07 +03:00

Author

Owner

@adpaco-aws commented on GitHub (Feb 5, 2026):

Agree, this would be great to have! 😄

However, I see a few issues with the cache_expiry flag and its values:

cache_expiry=0 is redundant with disable_cache=true, which can lead to confusion and conflicts
Milliseconds feels too granular, maybe we could use duration strings?
cache_expiry=-1 can be problematic for a few reasons. If we were using duration strings, we wouldn't need it because we could just set cache_expiry="9999years" or similar.

@adpaco-aws commented on GitHub (Feb 5, 2026): Agree, this would be great to have! 😄 However, I see a few issues with the `cache_expiry` flag and its values: 1. `cache_expiry=0` is redundant with `disable_cache=true`, which can lead to confusion and conflicts 2. Milliseconds feels too granular, maybe we could use duration strings? 3. `cache_expiry=-1` can be problematic for a few reasons. If we were using duration strings, we wouldn't need it because we could just set `cache_expiry="9999years"` or similar.

kerem commented

2026-03-15 11:50:12 +03:00

Author

Owner

@weibenz1 commented on GitHub (Feb 5, 2026):

I think cache_location is good to have! Exact details can be discussed in the upcoming PR

cache_expiry in seconds is a bit hard to manage - maybe we should do something like -cache-refresh-frequency and start with x number of hours (x being user input here) - if people ask for more granular frequency we can add support in future.

How does it sound?

@weibenz1 commented on GitHub (Feb 5, 2026): I think `cache_location ` is good to have! Exact details can be discussed in the upcoming PR cache_expiry in seconds is a bit hard to manage - maybe we should do something like `-cache-refresh-frequency` and start with x number of hours (x being user input here) - if people ask for more granular frequency we can add support in future. How does it sound?

kerem commented

2026-03-15 11:50:17 +03:00

Author

Owner

@Dianayin422 commented on GitHub (Feb 6, 2026):

Hi @C85297 , I'm Diana Yin, the PM for IAM Policy Autopilot. Thanks for sharing your feedback here. I'd love to hear more about your experience. If you're open to a quick chat, feel free to email me at dianayin@amazon.com and we can set up a time. Thanks!

@Dianayin422 commented on GitHub (Feb 6, 2026): Hi @C85297 , I'm Diana Yin, the PM for IAM Policy Autopilot. Thanks for sharing your feedback here. I'd love to hear more about your experience. If you're open to a quick chat, feel free to email me at dianayin@amazon.com and we can set up a time. Thanks!

kerem commented

2026-03-15 11:50:22 +03:00

Author

Owner

@C85297 commented on GitHub (Feb 9, 2026):

@adpaco-aws @weibenz1 thanks for the feedback - I'll make a PR based on this discussion and we can then work together on that.

@C85297 commented on GitHub (Feb 9, 2026): @adpaco-aws @weibenz1 thanks for the feedback - I'll make a PR based on this discussion and we can then work together on that.

kerem commented

2026-03-15 11:50:27 +03:00

Author

Owner

@C85297 commented on GitHub (Mar 13, 2026):

Hey all, I've been working on this in the background but unfortunately been quite busy so won't be able to submit a PR for at least a week. Apologies for the delay.

@C85297 commented on GitHub (Mar 13, 2026): Hey all, I've been working on this in the background but unfortunately been quite busy so won't be able to submit a PR for at least a week. Apologies for the delay.

kerem commented

2026-03-15 11:50:32 +03:00

Author

Owner

@mschlaipfer commented on GitHub (Mar 13, 2026):

Thanks for the update, no worries! Just FYI, we're hoping to publish a new release middle of next week, but we can include this change in the one after that.

@mschlaipfer commented on GitHub (Mar 13, 2026): Thanks for the update, no worries! Just FYI, we're hoping to publish a new release middle of next week, but we can include this change in the one after that.

kerem referenced this issue

2026-03-15 11:55:34 +03:00

[PR #119] [CLOSED] Fetch context dev #247

Rows
Columns

[GH-ISSUE #138] Add Service Reference cache control flags #119