A Full Walkthrough of What Infisical Honey Tokens Are and How They Work

The average data breach takes 241 days to detect. That's 241 days an attacker has to move laterally, escalate privileges, and do real damage. Honey tokens cut that to about 5 seconds.

Here's the idea. You plant fake credentials alongside your real ones. They look identical. They sit in the same secret store, but they have zero privileges. An attacker grabs them and tries to use them, and the moment they do, you're notified. They think they've got real keys, but what they've really done is trip your alarm.

Infisical just shipped honey tokens. In this video, I'll show you how to configure one, what happens when they're triggered, and how to manage them.

A honey token could be any kind of fake credential — AWS keys, a database password, API tokens — anything that looks real but exists purely as a trip wire. Right now, Infisical supports AWS IAM credentials, so that's what we're going to use in this demo.

Here's the mechanism. Infisical provisions a real IAM user in your AWS account with no privileges. It generates an access key for it and then stores that access key as a secret in the project and environment that you choose. From the outside, it looks identical to any other AWS credential in your secret store.

We watch CloudTrail for any API call made with that key. It doesn't matter what the call is — whether it's listing S3 buckets, fetching secrets from the secret store, even just calling GetCallerIdentity. Any AWS operation that uses that credential trips the wire.

The first time we see one, this token flips to triggered. Org admins get an email and the event lands on the dashboard with the API call, the source IP, and the region. The IAM user has no permissions, so the call fails, but the attempt is the signal.

Before we create honey tokens, Infisical needs a way to talk to your AWS account. It needs to be able to create and manage IAM users on your behalf. In Infisical, this kind of integration is called an app connection. There's also a CloudFormation stack we need to deploy — that's the piece that detects when a honey token credential has been used and then sends that event back to Infisical. We'll configure that second.

In the AWS console, go to IAM, then Roles, and click Create Role. For the trusted identity type, choose AWS Account, then choose Another AWS Account. Pull up Infisical's docs on honey tokens. Under the prerequisites, it says to create an AWS app connection at the org level with the following IAM permissions. Click on AWS App Connection — step three says to select Another AWS Account and provide Infisical's AWS account ID.

I'd also recommend enabling Require External ID. Paste in your Infisical organization ID, which you can find under Settings. This protects against the confused deputy problem — it makes sure that only your Infisical org can assume this role.

Click Next, give the role a name, and create it. Now add the permissions the role needs. Copy the JSON block from the docs, go back to AWS, click on your role, then Add Permissions, Create Inline Policy, switch to JSON, and paste it in. Create the policy.

Now back in Infisical, copy the role ARN. Go to the Infisical dashboard, click Integrations on the left side, then App Connections, and add an app connection. Assumed Role is fine as the method. Paste the ARN and click Connect to AWS. The app connection is live.

In Infisical, go to Organization Settings, then Product Settings. For the app connection, choose the AWS app connection you just created. There's also an autogenerated webhook signing key — this is the shared secret that AWS will use to sign trigger events on their way back to Infisical, so we know they're legitimate and not spoofed.

Click Next and Advanced Options. The stack name defaults to infisical-honey-tokens in us-east-1. You can override this if you want it elsewhere. Click Save. This points at a CloudFormation template that Infisical hosts. It passes your webhook URL and signing key in as parameters and uses the CAPABILITY_NAMED_IAM capability because the stack provisions named IAM resources in your account.

Copy the command and paste it into a shell with AWS credentials that can deploy CloudFormation in your target account. This takes about a minute. Once you see CREATE_COMPLETE, you're done.

Back in Infisical, click Save, then Verify Connection. You should see that your connection is deployed and healthy. The Connect button now shows Manage — this is where you'd come back to rotate the signing key, swap out the app connection, or change the region or stack name.

That's one-time work. From here on, any project member with sufficient permission can plant honey tokens.

Navigate to a project and select the prod environment at root. These are the real secrets that the app uses. We want to plant a decoy here so that if anyone breaks in and exfiltrates these secrets, the decoy goes along with it.

Click Add Honey Token at the top right and choose AWS. Confirm the environment is production. For the secret mappings, name these keys exactly how AWS keys would be named in a real environment: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. An attacker scanning the secret store wouldn't be able to tell the difference between these and any other AWS credential.

Click Next. Give it a name — something like prod-aws-honey. This is just an internal name for your dashboard and email alerts; an attacker would never see this. Optionally add a description, then click Create Honey Token.

Infisical provisions the IAM user, generates the key, and writes secrets into the path. This token now shows as active. Notice the decoy sits alongside real secrets. These sync to anywhere this folder syncs to — GitHub Actions, Parameter Store, anywhere else. The decoy follows the real credentials.

Let's act as an attacker who's grabbed these secrets. Copy the access key and secret key out of the dashboard and drop them into a shell:

export AWS_ACCESS_KEY_ID=<honey_token_access_key>export AWS_SECRET_ACCESS_KEY=<honey_token_secret_key> aws sts get-caller-identity

This attempt gets logged. Switch over to the Infisical dashboard and refresh the page — the token now shows as triggered. Click View Details and the event log shows the IP address, the action (GetCallerIdentity), the region, and a timestamp. Every org admin also gets an email with the same details and a link straight back to the dashboard.

That's the full loop. The credential is touched, the alert fires, and detection happens in seconds.

Resetting a token: If a trigger turns out to be benign — a teammate was testing or misconfigured a scanner — click Reset. This sets the token status back to active, hides past events, and rearms email notifications.

Revoking a token: If a trigger is real and you want the token gone, click Revoke and type in the token name to confirm. This deletes the IAM user and the access key in AWS, removes the decoy from the project, and marks the token as revoked.

Email throttling: Infisical sends one alert email every 24 hours. If you have a noisy attacker, your inbox won't get flooded. Every event still lands on the dashboard.

That is honey tokens in Infisical. Plant one, forget about it, and the day somebody actually touches your production secrets, you know about it in seconds. If you're already on Infisical, an admin can wire up the AWS connection and you can start planting honey tokens today. All of the docs mentioned are linked below.