Overview

AI governance involves providing guardrails for safely using AI systems. This can seem like an obtuse topic, but once we start approaching it systematically, we find that it breaks into concrete subproblems. A lot of these map to well-understood problems in cybersecurity, with a few twists here and there; the rest are novel, but can be framed as clear requirements.

The first two articles in this series covered the basics, breaking down AI governance into a set of specific problems, and sketching a wrapper+collector solution framework. This article goes deeper into the design of the wrapper and controller.

The wrapper code is in the wrapper directory in the repo.

Wrapper basics

To recap, the basic idea with building wrappers is to take the functionality that a gateway would provide, and have that run along with the service calling the AI system. This avoids the security and reliability issues of having a separate gateway intercepting all traffic to all AI systems. Wrappers can be of many shapes, but we will start with the simplest form, an externally vended library that the developer should include into their calling service before accessing an AI system. With Python being the most popular language for AI systems, let us star with a Python library, vended via pip.

The wrapper should intercept requests and responses between the calling service and the AI system. This can be done as an explicit step(s), or via monkey patching at some point in the call chain, all the way down to the base http call. Let’s pick a middle ground, where we require the developer to add an explicit step, but use monkey patching to make the step as simple as possible. Note that monkey patching has its downsides, and making the interception of requests/responses overly implicit also has downsides, especially when it comes to debugging. The right choice here might depend on the desired developer experience.

We are going to take the middle ground here, and provide a simple but visible interface.

The wrapper should have read/write access to the S3 bucket that will serve as the controller. More specifically, the wrapper should not have any innate access, but the calling service should have access that the wrapper inherits. The natural way to do this is by leveraging AWS IAM to let the role of the calling service (or IAM user, as the case may be) have appropriate access on the S3 bucket. We will explore this in more detail in the next article. For now, let’s assume that the wrapper has access to the controller S3 bucket.

Putting the wrapper to work

Now that we have a basic mechanism to intercept requests and responses, as well as a bi-directional communication path between the wrapper and the controller, we are ready to start implementing some AI governance features.

Data Loss Prevention

Let’s start with a simple one, Data Loss Prevention, or DLP. The idea here is to prevent the loss of sensitive information to external parties (in this case external AI vendors). The sensitive information is usually captured as keywords and specific patterns, such as phone numbers, SSNs, etc. To implement DLP, the requests being sent to the AI system should be scanned for presence of sensitive information. Instead of building a scanner from scratch, we can use a standard open source tool, such as Microsoft Presidio. Every enterprise would have their own unique DLP requirements. We can capture these requiurements as a dlp config, stored at the controller. The wrapper will fetch and cache these configs, and inject them into the DLP tool being used. Requests that contain sensitive inputs can be rejected/sanitized.

Abusive Content Detection

This is similar to DLP, but here, the idea is to analyze the inputs and outputs for abusive/inappropriate content. As with DLP, what constitutes abusive/inappropriate content depends on the enterprise and the situation. But we can implement a baseline level of filtering with open source tools. We will use the Detoxify library.

Audit Logs

The wrapper sends logs of all the requests and responses to the controller, including the ones that were blocked by DLP and abuse detection filters. These logs contain all the relevant metadata, including details of the environment of the calling service. We can write these logs directly to S3, or leverage CloudWatch. Along with audit logs, we can record metrics of various events, also using CloudWatch.

Anomaly Detection

Once access logs and metrics are available, we can scan them via async processes for anomalies, and act on them as needed. We can build our own anomaly detection systems, or leverage AWS tools such as Macie and GuardDuty.

Extending the controller

What we described above was a simple setup, with a basic controller leveraging S3 and some other AWS tools. Now let us explore how to open up the controller, by first making it easy to configure, and then enabling integrations with other security tools.

Configuring

Leveraging S3 to hold all the configs vended by the controller is a good idea - S3 is extremely reliable, and comes with built-in access control mechanisms. However, manipulating these configs directly on S3 can be awkward and error-prone. We can avoid this by providing a simple UI/CLI that updates the configs in this bucket behind the scenes.

Extending to other observability and security systems

The setup so far is constrained w.r.t what tools we can use for audit logs, anomaly detection, etc. To open this up, let’s leverage OpenTelemetry, an open, well-supported standard for telemetry. Speficially, the wrappers will leverage OpenTelemetry for audit logs and metrics. OpenTelemetry comes with its own client library, which the wrapper can use for transmitting logs and metrics. OpenTelemetry also comes with its own collector, which can be run as a standard HTTP/gRPC service. This service will receive telemetry data from client libraries and can be configured to export this data to other systems , such as Prometheus, DataDog, Splunk, NewRelic, etc. Once we have a basic OpenTelemetry-based controller set up, adding new systems that support OpenTelemetry is fairly straightforward.

In the repo, we have a basic OpenTelemetry collector defined in the otel-collector directory. It is fairly straightforward to extend this to support other systems. Consult the OpenTelemetry docs for more info.

Recap and Next Steps

In this article, we explored how a simple wrapper + controller setup with a Python libarary and S3 can get us off the ground by providing AI governance features such as Audit Logs, Anomaly Detection, Data Loss Prevention, and Abusive Content Filtering. To open things up even further, we can leverage OpenTelemetry, which supports a vast number of security and observability solutions out of the box.

In the next article, we will explore access control, and see how we can leverage it to turn our wrappers into effective chokepoints.