Michal Salanci
Senior Systems Engineer at ESET Cybersecurity
Košice, Slovakia
Actions
A Senior Cloud Engineer from Slovakia. For many years, I worked as a Data Center network engineer, handling various networking equipment such as routers, switches, firewalls, load balancers, and more. In 2021, I made a career shift towards AWS, where I primarily focus on networking, security, serverless and containers. I am AWS Community Builder in category Containers and also Leader of AWS User Group Kosice, Slovakia.
https://michalsalanci.com
Area of Expertise
Topics
Cloud Intelligence Agency: Special agents interrogating your AWS cloud
A team of AI agents is investigating the cloud environment.
User asks a question in plain English and the agents gather evidence from many different types of logs, events and API calls to produce the answer.
Instead of digging through gazillion of logs to get the answer, the agents turn questions into automated investigations.
The logs from multiple AWS resources are gathered into S3 Data Lake by automated data ingestion pipeline, where agents read it using Amazon Athena. To other services which don't produce logs the agents are connecting by API calls.
We’ll walk through the architecture behind it: a multi-agent system in Amazon Bedrock AgentCore runtime, agent memory, custom LLM guardrails, deterministic antihallucination and security hooks and ingestion pipeline.
Whole project is in terraform and available in git for everyone.
Let's get that cloud some interrogation, until we get the answer!
When managed guardrails aren't enough: lessons from a real Agentic use case
AI guardrails are often presented as a simple configuration problem: enable prompt-attack detection, block harmful content... and your agent is protected. In a real agent however a managed guardrails are only the beginning.
This talk follows the development of a Agentic AI project [https://github.com/msalanci/logs_talk_to_me/tree/v3], deployed in AWS Bedrock AgentCore runtime - a conversational agent investigating AWS logs using SQL query and AWS API calls.
Through specific failures we explore the point where managed guardrails stop being enough and where small, deterministic pieces of custom code become necessary, why system prompt cannot reliably prevent architecture leakage and how hooks can enforce rules before a tool is called or an answer is returned.
It is a practical guide for builders who want to understand what managed guardrails do well, where custom validation is unavoidable, and how to combine both without building an overcomplicated security system.
Target audience are agentic AI builders or anyone interested in guardrails for LLMs
Preferred talk is 30 minutes, but I can prolong it to 45 as well
Prompts are the requests but hooks are the guarantees: deterministic control in Strands AI agents
LLMs are probabilistic, but production systems still need deterministic guarantees. Improving your prompt may raise the odds but it cannot make the rule absolute and that's where you need a deterministic approach.
Using lessons from my Agentic AI project [https://github.com/msalanci/logs_talk_to_me/tree/v3] - a conversational agent investigating AWS logs using SQL queries and AWS API calls - this talk explores how deterministic hooks let developers intercept and control the agent while its reasoning loop is still running.
The focus is not an API tour, it's the broader engineering pattern: placing deterministic logic at agents' specific lifecycle events and how those hooks can inspect, modify, cancel, and retry model-generated actions before they affect.
Actions like return a correction message to the model, let the agent repair its own request, rewrite SQL queries, maintain state across tool calls, suppress wasteful retries, validate final answers, inject application context and more... all that can be provided by a deterministic hooks, assigned to an agent during the right event.
Finally, we will compare deterministic hooks with "LLM as judge" and establish a practical rule for choosing between them.
talk for 30 minutes, but I have enough material to extend it to 45.
No special technical requirement needed
Give your agent a memory (and it may be dangerous)
Your AI Agents can reason across complex problems, call tools and generate convincing answers—but the moment a request ends the agent forgets everything. Agentic memory is not just storage, it's a context that actively changes an agent’s behavior.
This talk explains what agent memory really is, why it must be built separately from the model and why adding it is more complicated than simply storing chat history.
Based on one of my projects - [https://github.com/msalanci/logs_talk_to_me/tree/v3] - a conversational agent investigating AWS logs using SQL queries and AWS API calls - we will explore the that matter in practical systems: short-term conversation history (running locally), along with AWS Bedrock AgentCore memory (Semantic for reusable facts, Episodic for repeated experience and Summary for session summation).
We will also look at the more dangerous side of memory, when a fact remembered from an earlier conversation was injected into an unrelated session, agent trusted it, changed the SQL it generated, and caused the query to fail. A memory that was correct once had become misleading context.
Give your agent a memory, but save less, retrieve narrowly, and trust deliberately.
no special requirements
Run your agents in Kubernetes: Build once, deploy anywhere. But really?
You know that - A demo works on your laptop, then you deploy it elswere and it's not. Migrating a Kubernetes workloads from one platform to another is not just flipping the switch.
I created the LLM app utilizing a small quantized open model (~4B, CPU-only, serving inside the cluster) running it on a local kind cluster on my M4 MacBook. However, once moved to the AWS EKS, the pod died with 'exec format error'.
The fix exposed the next failure, and the next... a liveness probe killing the model server mid-load, ':latest' meaning different images on different clusters, kubelet garbage-collecting the multi-gigabyte model weights, a hardcoded DNS suffix, a NetworkPolicy silently doing nothing.
Let's find out what lies between "works on my laptop" and "runs anywhere", because "Build once, deploy anywhere" is a claim you must earn.
Michal Salanci
Senior Systems Engineer at ESET Cybersecurity
Košice, Slovakia
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top