Credential Shield: No More Secrets In Your Pipeline

Credentials end up in logs more often than anyone would like. Usually not from every day events, but it happens often enough. Perhaps an application crashes and the error handler dumps a full request object, auth headers included. Or someone runs an AWS CLI command with a secret key as a flag and your process command-line logging captures the whole thing. Or maybe a CI/CD build step echoes its environment variables into a log that gets forwarded to your SIEM. Could be that a Lambda function errors out and its invocation log includes every environment variable it was reading from.

All of these happen and when they do, the credential sits in your SIEM or data lake until someone notices. Not great would be a pen tester noticing. Medium bad would be an auditor. Bad bad would be an attacker. 

Introducing Credential Shield

Credential Shield is a new pipeline processor that detects and redacts secrets inline, before events ever reach storage.

AWS access keys. Secret keys. Session tokens. GitHub personal access tokens. API keys across hundreds of vendor-specific formats. All caught at the pipeline layer and replaced with a [CREDENTIAL] token before the event goes anywhere.

It's keyword-anchored, meaning it looks for credential context before running the full pattern match. So it's fast, it's precise, and it doesn't slow your pipeline down.

One line of config and every event gets scanned. Secrets get replaced and field structure stays intact so your detections, schema, and routing keep working. The only thing that changes is your logs stop being a place where credentials can hide.

Reintroducing PII Shield

Credential Shield follows a similar pattern as PII Shield, which has been catching personally identifiable information in the pipeline since launch.

If Credential Shield is the insurance policy, PII Shield is the one that's earning its keep every single day. Emails, SSNs, credit card numbers, phone numbers, passport numbers, Medicare IDs, IP addresses, MAC addresses. If you're ingesting logs from SaaS applications, cloud infrastructure, or anything that touches end users, PII is in there. It showed up the moment you connected the source.

Same easy setup, same inline redaction, same "your downstream detections don't even notice" design. The big difference is frequency because PII shows up in basically every source. Together with Credential Shield, they cover the full surface.

Under the Hood

Both Shield processors do more than scrub and move on. Every event that triggers a match gets annotated with which rules fired, which fields were affected, and which processor did the work. You get a clean audit trail without having to go looking for it.

Shielding doesn't have to mean losing a thread. Both processors support a hash mode that replaces sensitive values with a consistent pseudonym. The same input always produces the same token so you can still see that three events belong to the same user and track patterns without exposing the underlying data.

And if a built-in rule doesn't fit your environment, disable it by name. Want to keep email addresses visible in a specific source? Turn off that one PII Shield rule. Everything else stays protected.

The Compliance Story

Logging credentials without controls is a risk. Logging PII without controls is a compliance problem. PCI-DSS has specific requirements around cardholder data in logs. HIPAA cares about PHI in places it shouldn't be. GDPR's data minimization principles get uncomfortable when your SIEM is retaining full email addresses for 12 months because nobody thought to strip them at ingest.

Sometimes compliance requirements conflict with security's goals. IP addresses under GDPR, for example, are personal data and some organizations can't store them raw. But if PII Shield just replaces every source IP with [IP_ADDRESS], you can't see that the same address just showed up across five different events in the last ten minutes. Again, hash mode is the answer here. With the IPs replaced with consistent pseudonyms, correlation and pattern spotting across sources is still possible even though the original value is never stored.

Credential Shield and PII Shield both give you a documented, auditable control at the pipeline layer. That's the one place in the architecture where every event passes through before storage. It's a conversation you can have with an auditor without needing an engineer in the room to explain how it works.

Available Now

Credential Shield is available to all Abstract customers as a standard pipeline processor. Drop it into any pipeline alongside PII Shield, scope them to specific sources or fields if you want precision, or run them zero-config and let the built-in patterns do the work.

Your logs have enough going on. Secrets and PII don't need to be part of it.