Model Access
For Bedrock, AWS has brought copies of dozens of AI models into their data centers.
In my first blog of this series, Can AI Be Trusted in High-Stakes Credit Reporting and Dispute Processes?, I wrote that the first steps to answering “Can I trust AI?” are to extend the question with two key parts:
With this blog focusing upon the information security aspects of using AI to help in credit data furnishing and disputes, I said that we would start with the question: “Can I trust AI tools to keep our data secure with as much confidence as I have today in other technologies?”
This critical question must be addressed before the business outcomes can even be considered.
We will supplement that question with “Can I trust AI tools to stay in their lane as well as I can other parts of my infrastructure?”
There are, of course, many more questions that we could ask, but these strike a balance between being broad enough to cover many sub-categories and focused enough to address in a blog.
At the end of this blog are a couple links to additional resources for those of you who are interested in going deeper.
Let’s take these questions in order.
To answer this question, you must first take a step back from the AI itself, considering the full solution and environment in which the AI operates. Information security is only as strong as its weakest attack vector, so an AI solution cannot be secure without securing the databases, data flows, authentication, and other critical InfoSec considerations that must be in place. This may be stating the obvious, but it’s critical to not lose the foundations when evaluating new types of tools.
Moving to the AI-specific considerations, the first question that many people jump to when thinking about AI tools is some version of “What model are you using?”
From a data security perspective, however, the better question is “What access are model providers getting to my data, and how are they using it?” The answers to those questions can be very different.
The best way to make sure that the companies building LLMs do not use your data is to make sure that they never receive it in the first place. That is why, at Bridgeforce Data Solutions, we wanted to keep the data within our secure environment regardless of the models we used.
To do this, we started using Amazon Bedrock in 2024 and it remains a key part of our infrastructure.
Model Access
For Bedrock, AWS has brought copies of dozens of AI models into their data centers.
Data Location
Those models can then be used without the data ever leaving the AWS data center, in our case US East in Northern Virginia.
Secure Perimeter
Bedrock enables us to work with the models available, with over 100 to choose from at this point, while keeping all data within our PCI-DSS perimeter.
In our case, we were operating PCI-DSS and SOC 2 audited environments for years before adding AI tools to the mix. The AI-enabled solutions that we have developed are in-scope for those audits. By having our AI tools in-scope for our PCI-DSS audits, we are treating all inputs and outputs to those tools with the same care as is industry-standard for things like credit card numbers and expiration dates.
Now let’s move on to the next question.
There have been many newsworthy instances at this point of AI models behaving differently than expected, so people are rightfully concerned about keeping any solution within its intended lane and also making sure that they can shut it down if they want.
Ensuring this is true starts with the solution design. Our AI solutions are narrowly focused and operate in a request-based way, which shapes how they behave from the ground up:
Narrow Focus
The tools and permissions available to our solutions are very limited, in some cases limited to read-only.
Request-Based
Operating in a request-based way means that the tools take action only once called upon.
Simple Kill Switch
The concept of a “kill switch” is simple: it involves the cessation of making requests.
Lower Inherent Risk
This structure keeps the inherent risk for our solutions low from this perspective.
The picture looks very different for solutions with much greater agency. An AI solution designed to handle a wide array of tasks and overcome obstacles would require capabilities that could be harder to contain. This would greatly increase the inherent risk from this perspective, and make shutting it down potentially harder.
Solution design and build is then followed by testing. This involves scanning for vulnerabilities in code and the environment, logging, and 24/7 monitoring to ensure that any unusual activity is quickly detected.
For those of you interested in going deeper in a general sense, here are a couple links to informative public sources:
NIST
I first interacted with NIST over 25 years ago as part of certifying cryptographic tools we had built at the company I led at the time. They were thorough and helpful back then, and they still are with AI.
Read more →OWASP
OWASP is another organization that provides lots of valuable resources, and this page provides links and updates to many resources focused upon security for generative AI.
Read more →