Can you see from the call stack in the exception where it is thrown from? My guess is that there are some event handler that listens to e.g. IContentEvent.PublishedContent and in the event handler re-saves that content instance (but without AccessLevel.NoAccess)
I have code to create media assets (in this example image files) which was previously working but now gives the access denied exception. The same accesslevel mechanism seems to work fine for pages and blocks. NOTE: this is a slightly hacked up version showing the mechanism used, but mechanically is the same as code that previously worked. So I'm wondering if anyone has ideas on where else to be looking in terms of what changed? One question I have is why does it say it needs Edit access when we are creating the asset (or does the GetDefault actually do the create?) Could it be related to needing edit access to the parent folder into which the asset is going?
I have an update, after poking around I found that contrary to the exception itself, the ImageFile is in fact being created in the proper folder. So the question is, why when it appears to be actually performing the Save am I getting this Exception?