High Compliance Environments

Engineers and product managers in high compliance environments know their organizations are going to be slow to adopt AI in their environments because they already have so much governance and red tape that it's nearly impossible to make any updates in a risk-aware environment with compliance baked into the process. Ya'll working in health insurance, banking, communications, government contracts with regards to national defense and beyond all know the trials of high-compliance and regulations like SOC2, HIPAA, PCI and dealing with PII in secure environments.

The CISO's understand the security implications of allowing more chaos into the environment via a probabilistic agent operating in the environment, let alone a human. The difference is the human is bound by the legal agreements and contracts we make whereas the LLM is bound by what it digitally has access to and can actually/literally do. By the way, not all threats are of a malicious nature, some of them are out of sheer oblivion and others are out of a ruthless path to completing the task at hand. For example, new sysadmins can be oblivious of the environment they are accessing when restarting the database or an LLM could wipe out an entire production database because it read the word "cleanup" from an unclear prompt.

In this post, I am going to break down the concerns on the minds of a lot of InfoSec officers in high compliance environments so you can have a plan for counter measures and ensure your app is better positioned for compliance and acceptance.

1. Auditability/Traceability

If something goes wrong, can you track down how it happened? Who requested it? What was the request?

If not, you need to log more and build an audit trail. That means for every change that happens in the system, create a table of "old state" & "new state" of sorts. Make sure to track when and who made the change as well.

If you do this, at least in a situation where you need to understand how something came about, you can track it down in the audit log. I've been in situations where I've wanted to "undo" and couldn't because I didn't track what I was doing.

If you are building custom tooling like agentic harnesses and in-house apps, you'll want to make sure some component of your application includes these as well.

Git is a great solution to code for this. It has authorship, it has a before and after state awareness. Its distributed and decentralized nature also makes it easy to create pockets of functionality change over time and keep a record of what happened in those changes.

2. RBAC: Identity and Authentication

This is two-fold: User interfacing with agent and agent interfacing with tools.

You need to know who's interfacing with your application/agentic system. Not all roles interfacing with the agentic system will have the same access. You need to log who interacts with the app as well to understand who requested what.

The agentic system also needs to authenticate against services it uses. It's good practice to have a matrix of access to make it easy for CISO's to digest the access requirements.

Solving this problem on both ends of the spectrum will help your case when building an agentic system in your organization. The latter though leads nicely into our next point.

3. Data Access Controls

It's one thing to authenticate to a service or third party system or services. It's another thing to be authorized to take action or access data.

This includes filesystem permissions, oauth2 data access policies, app permission manifests and just understanding the full capabilities. The agent may be probabilistic, but your system and harness is not. You can be deterministic about what access it has just as you do with any other associate or application in your organization.

4. Network & Resource Access

There have been countless reports on data exfiltration attacks where information is leaked. As a former cybersecurity engineer, I saw a lot of compiled exploits and a common theme showed up in my research: They have to "phone home" somehow and a lot of the time, it's on non-standard ports.

Securing your network will go a long way against preventing this and locking down agentic systems to the most predictable or deterministic paths will have the most effect on ensuring nothing out of the expected happens.

If an agent shouldn't have access to the database, then it shouldn't see the database in the local network. If an agent makes web requests, then permit only 80 and 443 to the sites you trust instead of global outbound access. This reduces the chances of communications where you didn't expect them.

5. Content Filtering & Input Controls

You'll want to make sure you have some kind of mechanism to ensure secrets don't get into the context window. We don't want the model using them to access other tools, services and whatever else is going on. We also don't want threat actors getting access to secrets either.

In local development, I would recommend using dotenvx instead of dotenv in your environments to at least minimize the off chance a .env file gets read.

6. Backup and Disaster Recovery

You need to take regular backups and checkpoints to ensure the system can revert in case of issues. In a chaotic environment, disaster is going to strike, it's just a given. The thought process is not to prevent that from ever happening, but being in a position where recovery is possible at the click of a button.

The last thing you want is for an agent to optimize for "cleaning up the system" involving truncating all your customer data.

---

The Takeaway

The idea behind all of this is predictability: Taking a probabilistic system that may take a variant of actions and putting guardrails in place to coerce the capabilities to be auditable, traceable, secure and understandable. The more predictable your agentic systems and apps are, the better chances you have at gaining a compliance stamp.