Democratize Log Access with AI

Hola everyone, I´m Diego from diegowritesa.blog

After taking most SANS AI courses, SEC495, SEC545 & SEC595 - I felt like sharing some of my thoughts on how security fits into the AI world, and why it’s so important to consider from the very beginning.

You can find me on L inkedin & T witter - These blogs take quite a bit of time to put together, and they’re all just meant to share knowledge. Any comments, requests, or connections are always much appreciated — love you all! ❤️

Today, we’re talking about using AI to empower your engineers, developers & auditors whenever they need logs.

-----------------------------------------------------------------------------------------------------------------------------

Executive Summary

"Democratize Log Access with an AI Abstraction Layer. Empower your developers, engineers and auditors to get the right information avoiding bottlenecks"

-----------------------------------------------------------------------------------------------------------------------------

Why does everyone need Logs?

Because logs are good. They contain lots of information, and that information can be used for many purposes such as: troubleshooting, auditing, security, etc.

1. Logs

That's why we should democratize access to logs. I don't know about you, but chances are, depending on the size of your company, the Security team hoards logs and all other teams need to figure out a way to get by with their applications and so on. Or maybe you are very lucky and you have a dedicated Log team, and nothing I am going to explain here resonates with you. Anyhow, this is my approach to solving this issue.

AI Abstraction Layer

The concept of abstraction layers is nothing new—often called "middleware"—we are simply repurposing AI for what we care about: logs. In short, it acts as a translator between our application and the end-users.

You can see below an example of a recurrent request I tend to deal with. The audit team wants to get all sign-in logs for a particular app over a period of time.

2. AI Abstraction Layer

Now, I hope this extremely simplified diagram is enough to make you understand what it is that we are building here.

This is not only useful for audit, but think of empowering all your developers and engineers to troubleshoot their own issues. If the network team can "naturally query" their firewall logs to troubleshoot why something is not working, it clearly saves a lot of time and back-and-forth gathering logs.

How do we build this?

Let's do a prototype of the proposed solution on our localhost. You will need a workstation/laptop (ideally) with 32-64GB RAM and at least a graphics card (8GB) to make this work and not make it painfully slow.

Let me present yet another diagram of how this is built:

3. Prototype Architecture - locahost

We make our request to an LLM using natural language, using Gradio for the front-end—very easy setup. We ask "What is the user 'diego' googling?"
Gradio sends the query to our Jupyter Lab instance where we have Ollama running. Here we send the request to our "Core LLM." This can be split however we want; I will elaborate more on this later. Our Core LLM has a pre-prompt and Modelfile explaining that they are EXPERT translators between human language and your language of choice to make the API request (SPL, Logscale, Crowdstrike SPL, etc.), and the goal for the CoreLLM is to translate the request into an actionable query.
After our query is returned, we send it to an agent, the "Refiner," whose task is to double-check the query and enhance it. For example, if we are asking "What is 'diego' googling?", the CoreLLM might create something like:

[type=proxy | *diego* | google.com | search]

The Refiner, on the other hand, will get the query and make sure it is built in an optimal way for our SIEM. In this case, it will wrap it around fields for speed and remove unnecessary loose ends.

[type=proxy | user="diego" | host="google.com" | search | table[field1, field2, field3]]

This query is then sent to the "Auditor," whose sole role is to verify if the syntax is correct. We can do it with an AI, API calls, dedicated libraries—whatever you prefer. I choose to do it via AI.
After the Auditor accepts the query, we can run some hardcoded logic guardrails. This is to prevent different users from accessing information they should not query, in case your API does not allow you specific index-querying. This is an optional step anyway.
Now we can send the API call to our SIEM and retrieve the logs.
Optional step again: feel free to check if the LLM returns data that the user is able to read; if not, drop it before it reaches the user.
Lastly, we send it back to the front end.
And it is presented back to the user.

Disclaimer & Considerations

This is a very, very basic setup, but it works. Of course, should you want to make this production-ready, there are many more aspects to consider from the AI perspective.

This approach does not rely on fine-tuning, which would be the preferred option for your "CoreLLM" to ensure a known formatted output is guaranteed (this is what you need for consistency).

To make this even better, you would use another fine-tuned LLM for your "Refiner." This time you can feed all information pertaining to your querying language—SPL, Logscale, etc. Make sure the LLM gets all the fields, what they are used for, and sampling queries to correlate.

And even better, if you get unlimited hardware, you can have different specialized LLMs for different purposes. They do not need to be based on the same—let's say Llama—feel free to experiment to see what works best. I did my testing with:

my-llama-70b:latest (70.6B, Q4_K_M)
nemotron-nano-12b:latest (12.3B, Q3_K_M)
gemma-3-1b-it:latest (999.89M, Q4_0)

All quantized models, thus no tuning for me. This was due to hardware limitations. You could also run a classifier before the request to use a bigger or smaller LLM depending on "how difficult" the request is.

Lastly, those hardcoded local guardrails might not be needed, depending on your API access and how you interact with your SIEM. In my testing, I have not found the ability to query per index or log source, thus manually implementing logical controls. This is something as simple as:

if any(log_type != "Log_Source_of_your_choice" for log_type in type_matches):
    raise ValueError("❌ Department A is restricted to type=X queries only.")
return query

Are there ways to bypass this? Of course, but it is a very good start. If you fine-tune your CoreLLM to ensure consistent output, you can also provide the LLM with direct querying abilities to the API. I was just not confident enough that this is the right approach.

We are also outputting chain-of-thought on all LLMs for logging purposes. You can monitor prompts and add guardrails to your system.

On the legal/governance aspect, friendly reminder for those folks in the EU: if you want to fine-tune an LLM, be careful with the AI EU Act and document everything you are doing!

4. Command Line example of AI-translation layer working

How do we build this, in the cloud?

As you might have guessed already, this prototype can be easily replicated in your favourite cloud as well.

5. Cumulonimbus a.k.a "Cloud"

This would be as simple as re-architecting 3. Prototype Architecture - locahost

If you want to remove the burden of hosting an LLM, connect to Amazon Bedrock, Azure Foundry, Grok, OpenAI API, Claude, etc., and replace the middle Jupyter Lab bit with an API call to your provider.

Just make sure that without proper prompts, or ideally fine-tuning, this can easily go wrong, so take that into consideration before starting to build your AI abstraction layer.

As always, pros and cons: less flexibility at a potentially lower cost, less maintenance, and if you can make it work for your use case, it could be the best solution.

Gradio can be replaced with whatever you want as well. This could all run on an EC2 with a couple of API calls to your favorite AI provider and hardcoded guardrails on a Lambda or equivalent before calling your logs.

AWS Migration Checklist

Gradio Frontend → AWS Amplify or ECS/Fargate containers

Jupyter Lab + Ollama → Amazon Bedrock or SageMaker
Local LLMs → Bedrock Foundation Models (Claude, Llama, etc.)
API Gateway → AWS API Gateway
Security Controls → AWS Lambda functions

Frontend Layer:

Deploy Gradio app on AWS Amplify for serverless hosting
Alternative: Containerize with Amazon ECS/Fargate for more control
Use CloudFront CDN for global distribution

API Management:

API Gateway to handle incoming requests with rate limiting and authentication
AWS Cognito for user authentication and role-based access control
AWS WAF for additional security filtering

AI Processing Layer:

Amazon Bedrock for managed LLM access (Claude, Llama 2/3, Titan)
AWS Lambda functions for each AI agent:Core LLM Lambda (query translation)
Refiner Lambda (query optimization)
Auditor Lambda (syntax validation)

Step Functions to orchestrate the multi-agent workflow

Security & Guardrails:

AWS Lambda for hardcoded logic guardrails
AWS IAM roles for fine-grained permissions
AWS Secrets Manager for API keys and credentials
AWS CloudTrail for audit logging

SIEM Integration:

VPC Endpoints for secure connectivity to on-premises SIEM
AWS PrivateLink for secure API calls

Monitoring & Logging:

CloudWatch for application monitoring and logging (Cloudtrail)

Cost Optimization:

Use Bedrock On-Demand pricing for variable workloads
Lambda pay-per-execution model
S3 for caching frequent queries
ElastiCache for session management

Azure Migration Checklist

Gradio Frontend → Azure Container Apps or Azure App Service
Jupyter Lab + Ollama → Azure OpenAI Service or Azure ML
Local LLMs → Azure OpenAI GPT-4/3.5 or Azure ML Models
API Gateway → Azure API Management
Security Controls → Azure Functions

Frontend Layer:

Deploy on Azure Container Apps for serverless containers
Alternative: Azure App Service for traditional web app hosting
Azure Front Door for CDN and global load balancing

API Management:

Azure API Management (APIM) for API gateway functionality
Azure Active Directory (Entra ID) for authentication
Azure Application Gateway with WAF for security

AI Processing Layer:

Azure OpenAI Service for GPT-4, GPT-3.5-turbo access
Azure Functions for each AI agent (similar to AWS Lambda):

Core LLM Function (query translation)

Refiner Function (query optimization)
Auditor Function (syntax validation)
Azure Logic Apps for workflow orchestration

Security & Guardrails:

Azure Functions for custom guardrail logic
Azure RBAC for role-based access control
Azure Key Vault for secrets management
Azure Monitor for comprehensive logging

SIEM Integration:

Azure Private Endpoints for secure connectivity
Azure Service Bus for message queuing

Monitoring & Analytics:

Azure Monitor and Application Insights for telemetry
Azure Log Analytics for centralized logging
Azure Sentinel integration for security monitoring

Cost Optimization:

Azure OpenAI consumption-based pricing
Azure Functions consumption plan
Azure Cosmos DB for caching with auto-scaling
Azure Redis Cache for session state

Final Remarks

Prototyping this takes a bit of effort, but the real challenge is scaling this to a production-level product. Fine-tuning the right LLM for your right fields, for your API access, and for your SIEM product is where most of the effort should be directed.

For any questions, comments, or ideas, as always, please do reach out. I read all your comments and am happy to help!"

Consider taking SEC595: Applied Data Science and AI/Machine Learning for Cybersecurity Professionals if this was interesting enough to learn more about it!

References & More Useful Information

My GitHub - HERE
AI For everyone, recommended course - HERE

Search This Blog

Diego Writes a Blog