I used AI the way I would use a careful technical editor. It helped organize dates, turn notes into a coherent report, draft public language, and pressure-test whether a sentence was helpful or too revealing.

That distinction matters. AI should not be used to escalate a finding past the ethical boundary. In this workflow, it helped me stay inside the boundary by clarifying what I had, what I did not do, and what did not belong in public.

This is also where orchestration becomes interesting. A tool like OpenCLAW could coordinate evidence collection, redaction checks, disclosure drafts, remediation checklists, portfolio artifacts, and publishing steps without losing the human approval points.

The future-facing lesson is not that AI finds everything. It is that AI can help responsible researchers communicate with more discipline when the stakes are real.

If a secret ships in a client app, assume it is public. The remediation path should start with revocation and log review, then move to architecture: replace static client credentials with backend-mediated access or temporary credentials appropriate to the workload.

AWS's IAM guidance emphasizes temporary credentials for workloads where possible, least privilege, access review, and safe handling of access keys when long-term credentials are unavoidable.

The practical controls are familiar: secret scanning, code review checks, build artifact review, narrow IAM policy scope, CloudTrail review, and a release process that treats mobile binaries as public artifacts.

Useful references: AWS IAM security best practices and AWS access key management guidance.

The public write-up included the affected package, observed builds, cloud target, region, endpoint, redacted access key identifier, technical source locations, and a clear statement that the full secret access key was not published.

It also included the research limits. No live AWS authentication was performed. No bucket enumeration, object retrieval, upload, write testing, or other AWS API activity was performed with the exposed secret.

That was the balance I wanted: enough specificity for accountability, enough restraint to avoid creating a new risk.

The disclosure document is available here: VapeTM Hardcoded AWS IAM Credentials – Public Disclosure.

In that separate thread, VapeTM stated that machine ID scanning does not collect or store information and that mobile-app ID scanning is handled by AptPay.

I would not present that as part of the AWS credential finding. It is adjacent context, not the same issue. Still, the conversations rhyme because they are both about trust boundaries in operational software.

For builders, this is where product maturity shows up. Secrets management, privacy claims, vendor dependencies, logging behavior, and customer-facing explanations all shape whether users can trust the system.

The careful version is stronger: I can say what was observed, what was vendor-stated, and what remains separate without stretching one finding into another.

This is the part of disclosure that is easy to understate. There was no reason to expand the scope once the issue was reportable. More probing would have created more risk without improving the core finding.

I kept the timeline organized, preserved the static-analysis evidence, and started thinking about what a public version could say without publishing material that would enable misuse.

That redaction work is part of the disclosure process. It forces the question: what helps other builders learn, and what only helps someone exploit an old mistake?

The remediation window is a trust exercise. My job was to be precise, patient, and ready to publish responsibly after the issue was addressed.

The report focused on what the vendor needed: affected application package, observed affected builds, source locations, target bucket, region, endpoint, and the credential values required for them to identify and revoke the key.

I also described my research limit. The finding was based on APK static analysis and decompiled code review only. No live AWS validation was performed.

That separation matters. The vendor needs enough detail to remediate. The public does not need enough detail to reuse the credential.

A good disclosure report makes the vendor’s next action obvious: revoke the exposed key, review logs, replace the pattern, and verify that newer builds no longer ship the secret.

The review stayed inside the APK and its decompiled source. I looked for where the values were defined, where they were passed, and what service client they were used to construct.

The relevant path was straightforward: build-time constants were used to create AWS credentials, and those credentials were passed into S3 upload code. I documented the affected package, observed builds, source locations, bucket name, region, and endpoint.

I did not authenticate with the credential. I did not enumerate the bucket. I did not retrieve objects, upload files, test writes, or call AWS APIs. The finding was validated through static evidence only.

Responsible validation is not the same thing as maximum validation. For this finding, static analysis was enough to show the risk and prepare a report.

The finding came from normal reverse-engineering work on software attached to equipment I owned. I was trying to understand how the Android vending-machine APK behaved and how it interacted with the rest of the system.

That is an important distinction for me. I was not hunting for someone else's cloud account. I was trying to map a machine I was operating. The credential surfaced while I was reading the application package and following what the code appeared to do.

The moment a long-term AWS IAM credential pair appeared in application constants, the task changed. This was no longer just operational research. It became evidence that needed to be handled carefully.

The first lesson is not technical. It is posture: when a normal engineering investigation exposes a secret, stop treating it like trivia and start treating it like disclosure material.