<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Abhishek Kalu</title>
    <description>The latest articles on DEV Community by Abhishek Kalu (@abhikalu).</description>
    <link>https://dev.to/abhikalu</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4200888%2Fdfb06e84-5368-441c-b542-3733bcaf2997.png</url>
      <title>DEV Community: Abhishek Kalu</title>
      <link>https://dev.to/abhikalu</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/abhikalu"/>
    <language>en</language>
    <item>
      <title>Most AI Chatbots Send Customer Data Straight to the Model. Here's the Layer We Built to Stop It.</title>
      <dc:creator>Abhishek Kalu</dc:creator>
      <pubDate>Thu, 22 Oct 2026 17:19:46 +0000</pubDate>
      <link>https://dev.to/igrisecurity/most-ai-chatbots-send-customer-data-straight-to-the-model-heres-the-layer-we-built-to-stop-it-a51</link>
      <guid>https://dev.to/igrisecurity/most-ai-chatbots-send-customer-data-straight-to-the-model-heres-the-layer-we-built-to-stop-it-a51</guid>
      <description>&lt;h3&gt;
  
  
  The pattern we kept seeing
&lt;/h3&gt;

&lt;p&gt;We've talked with a lot of teams shipping AI features. Support chatbots, internal assistants, agents wired into customer records. Different products, different stacks. And one thing kept showing up.&lt;br&gt;
There was no security layer at all.&lt;/p&gt;

&lt;p&gt;A user typed something into the chatbot. It went to the agent. The agent passed it to the LLM. Nothing in between looked at what was being sent. If a customer pasted their credit card number into a support chat, that number went to a third-party model, word for word. If someone tried to push the bot into misbehaving, nobody was watching.&lt;br&gt;
Nobody built it this way on purpose. Teams were moving fast, the demo worked, and security was going to be "phase two." Phase two rarely shows up.&lt;/p&gt;

&lt;h3&gt;
  
  
  A checkpoint in the middle
&lt;/h3&gt;

&lt;p&gt;So we asked a simple question. What if every LLM call had to pass through a checkpoint first?&lt;/p&gt;

&lt;p&gt;That's the idea behind Igris. It sits between your application and the model, and every prompt goes through it. Igris reads the full prompt, checks it against your policies, and if anything breaks a rule, the call is blocked before it reaches the model.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fvny8hnw75i7t77hin3ab.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fvny8hnw75i7t77hin3ab.png" alt=" " width="800" height="294"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Clean prompts go on to the model. Anything that breaks a rule is blocked or redacted, and every request is logged either way.&lt;/p&gt;

&lt;p&gt;Your developers don't have to rebuild anything for this. Igris speaks the same API format as OpenAI, so the app keeps making LLM calls the way it always did. Each call just takes a short detour through a layer that knows your rules.&lt;/p&gt;

&lt;h3&gt;
  
  
  What the policies actually block
&lt;/h3&gt;

&lt;p&gt;The policies themselves are practical. Most teams want the same short list kept away from the model:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Email addresses&lt;/li&gt;
&lt;li&gt;Phone numbers and other contact details&lt;/li&gt;
&lt;li&gt;Social Security numbers&lt;/li&gt;
&lt;li&gt;Credit card numbers&lt;/li&gt;
&lt;li&gt;Any other personal data your industry treats as sensitive&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;None of this is exotic. It's the data that turns an ordinary chatbot conversation into a compliance problem. When Igris finds it in a prompt, it can block the call outright or redact just the sensitive part, depending on how you set the policy.&lt;/p&gt;

&lt;h3&gt;
  
  
  When one user hammers the chatbot
&lt;/h3&gt;

&lt;p&gt;Rules catch bad content. They don't catch bad behavior.&lt;/p&gt;

&lt;p&gt;Picture one user firing message after message at a company's chatbot. Each message might look harmless on its own. Together they look like someone probing for a weakness, scraping answers, or running up the token bill.&lt;/p&gt;

&lt;p&gt;Igris watches for that pattern. When a single user suddenly bombards a customer's AI with messages, it detects the anomaly and raises a flag, so the team can look into it before it turns into a real problem.&lt;/p&gt;

&lt;h3&gt;
  
  
  Log everything, and anomalies stand out
&lt;/h3&gt;

&lt;p&gt;You can't spot strange behavior if you don't know what normal looks like. That's why Igris logs every request a user sends to our customer's AI. Every single one.&lt;/p&gt;

&lt;p&gt;Those logs do two jobs. Day to day, they're the baseline that makes anomalies visible. And when something does go wrong, they're the record that shows who sent what, when, and what happened to it.&lt;/p&gt;

&lt;h3&gt;
  
  
  Protection in both directions
&lt;/h3&gt;

&lt;p&gt;We think of this layer as protecting two sides at once.&lt;/p&gt;

&lt;p&gt;On one side are your customers. The personal data they share with your chatbot shouldn't end up held by an AI agent. Igris stripped out the sensitive and confidential data before agents sees it. Igris can remove or redact the sensitive data and then send it to the agent.&lt;/p&gt;

&lt;p&gt;On the other side is your company. The chatbot you put in front of the public shouldn't become something users can exploit. The same layer that checks what goes in also watches how people are using it.&lt;/p&gt;

&lt;h3&gt;
  
  
  What this looked like for one client
&lt;/h3&gt;

&lt;p&gt;We have seen many companies where their user share sensitive data wihtout noticing that might be used for different purpose or user sometimes as for different user data where this problem get more interesting. Igris catch any sensitive data like credit card number, medical report numbers, SSN, email, phone number, etc. Igris give logs where all user queires are stored, flaged, or blocked.&lt;/p&gt;

&lt;h3&gt;
  
  
  Three questions to ask about your own AI app
&lt;/h3&gt;

&lt;p&gt;If you're not sure whether your chatbot has a middle layer, these will tell you fast:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;If a user pastes a credit card number into your chatbot, where does it go?&lt;/li&gt;
&lt;li&gt;Would you know if one user sent hundreds of messages in a few minutes?&lt;/li&gt;
&lt;li&gt;If a customer asked what your AI did with their data last week, could you show them?&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;If any answer is "I'm not sure," that's the gap.&lt;/p&gt;

&lt;p&gt;Most of the teams we talk to aren't careless. They just never put anything between their users and the model. Adding that layer doesn't have to slow anyone down, and that's the reason we built Igris.&lt;/p&gt;

&lt;p&gt;Want to see what's passing through your own AI app? &lt;a href="https://www.igrisecurity.com/" rel="noopener noreferrer"&gt;Try Igris&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>cybersecurity</category>
      <category>mcp</category>
      <category>startup</category>
    </item>
    <item>
      <title>Scaling AI Security: From Single Agent to Enterprise Fleet</title>
      <dc:creator>Abhishek Kalu</dc:creator>
      <pubDate>Thu, 22 Oct 2026 16:55:02 +0000</pubDate>
      <link>https://dev.to/igrisecurity/scaling-ai-security-from-single-agent-to-enterprise-fleet-1j36</link>
      <guid>https://dev.to/igrisecurity/scaling-ai-security-from-single-agent-to-enterprise-fleet-1j36</guid>
      <description>&lt;p&gt;Your organization likely started with a single AI agent for a specific use case. Perhaps a customer service chatbot, a data analysis assistant, or an automation script for internal workflows. The project succeeded, delivered value, and proved that AI agents can transform operations. Now your teams are asking about deploying more agents across different departments and use cases. The challenge is that managing ten or hundred agents requires fundamentally different approach than what worked for one.&lt;/p&gt;

&lt;p&gt;The reality is that manual governance approaches do not scale. Security reviews that worked for one agent become impossible when you have fifty. Individual approvals for every tool connection break down when teams deploy agents daily. Spreadsheets for tracking access and permissions cannot keep pace with automated systems. Your governance model that enabled first deployment becomes a bottleneck for growth.&lt;/p&gt;

&lt;h2&gt;
  
  
  Architecture Patterns for Scale
&lt;/h2&gt;

&lt;p&gt;Distributed governance provides flexibility that centralized systems cannot match. Instead of routing every agent request through a single approval gateway, consider federated models where departments or teams maintain their own policy engines. These local engines evaluate requests against relevant rules and handle approvals for common cases autonomously, escalating only exceptions to central governance teams. This approach reduces bottlenecks while maintaining consistent standards across organization.&lt;/p&gt;

&lt;p&gt;Hierarchical policies enable efficient rule management at scale. Rather than defining separate rules for every single agent, create policy hierarchies with base rules that apply universally, team-specific rules that build on top of base, and agent-specific exceptions for unique use cases. When you need to update a security requirement, change it once in the base policy and it applies to all agents automatically. This structure prevents rule explosion while allowing necessary customization.&lt;/p&gt;

&lt;p&gt;Event-driven architectures support thousands of concurrent agents. Design your governance systems to handle agent actions as discrete events rather than holding connections open for real-time decision making. An agent requests access, governance system evaluates against policies, grants or denies access, logs the decision, and closes connection. This event-driven approach eliminates state management complexity and enables horizontal scaling across many agents without linear performance degradation.&lt;/p&gt;

&lt;h2&gt;
  
  
  Policy Management at Enterprise Scale
&lt;/h2&gt;

&lt;p&gt;Policy inheritance prevents duplicate work and inconsistencies. Define master policies for common requirements that apply across your entire organization, then allow teams to define local policies that inherit from these masters. When you need to tighten a security control, update the master policy and all dependent policies automatically reflect the change. This approach saves time and ensures consistency while still allowing local customization for specific needs.&lt;/p&gt;

&lt;p&gt;Automated policy testing catches regressions before they cause problems. Maintain a library of test scenarios that represent common agent behaviors and security requirements. Whenever a policy is created or modified, automatically run it through these tests to verify it behaves as expected. This testing prevents unintended policy changes from breaking legitimate agent operations while catching errors that security reviews might miss.&lt;/p&gt;

&lt;p&gt;Policy versioning enables safe rollbacks and auditing. Every time a policy changes, create a new version with clear documentation of what changed and why. Keep previous versions active with deprecation warnings so that agents can transition gradually. When a new policy causes unexpected issues, you can quickly revert to previous version while you investigate and fix the problem. This approach reduces risk of policy changes while supporting compliance audits that track policy history.&lt;/p&gt;

&lt;h2&gt;
  
  
  Automation for Human Efficiency
&lt;/h2&gt;

&lt;p&gt;Automated enforcement handles routine decisions that should not require human review. Implement automated approval workflows for common, low-risk scenarios like accessing public data sources, using standard tools, or operating within defined access boundaries. Reserve human review for genuinely novel situations, exceptions to policy, or high-risk actions like accessing sensitive customer data. This approach reduces review backlog while focusing human attention on cases that actually need it.&lt;/p&gt;

&lt;p&gt;Automated monitoring provides continuous visibility without manual effort. Configure systems to automatically track metrics like number of active agents, policy violation rates, response times, and system health. Set up alerts for anomalous patterns that might indicate security issues or policy problems. Automated dashboards aggregate this data and present it to appropriate stakeholders without requiring manual report generation. This continuous visibility enables proactive management instead of reactive firefighting.&lt;/p&gt;

&lt;p&gt;Automated remediation reduces response time for common issues. Implement self-healing mechanisms for routine problems like automatically revoking credentials when agents are decommissioned, rotating expired access tokens, or triggering incident response processes when threshold violations are detected. These automated responses handle the majority of routine incidents, letting your team focus on complex issues that require human judgment and decision making.&lt;/p&gt;

&lt;h2&gt;
  
  
  Multi-Tenant Considerations
&lt;/h2&gt;

&lt;p&gt;Organizational boundaries require clear separation. Different business units may have different security requirements, data access needs, and compliance frameworks. Implement tenant isolation at your governance layer so that policies, monitoring data, and incident workflows are properly separated between departments or business units. This isolation prevents one team's policies from inadvertently affecting another and enables appropriate access controls for different regulatory environments.&lt;/p&gt;

&lt;p&gt;Role-based access control scales more effectively than individual agent permissions. Define roles at organizational or team level rather than assigning permissions to each individual agent. Agents inherit permissions based on their role, department, or project assignment. When you need to change access for an entire class of agents, update the role once and all dependent agents automatically reflect the change. This approach reduces management overhead and ensures consistent access patterns across your agent fleet.&lt;/p&gt;

&lt;p&gt;Environment-specific policies support development versus production needs. Your development, staging, and production environments likely have different security requirements. Development agents may need broad access for testing and debugging, while production agents should have strict, least-privilege access. Implement policy engines that can apply different rule sets based on environment context. This enables developers to work efficiently while production systems maintain strong security boundaries.&lt;/p&gt;

&lt;h2&gt;
  
  
  Performance Optimization
&lt;/h2&gt;

&lt;p&gt;Batch processing reduces overhead compared to individual request handling. Design your governance systems to evaluate multiple policy checks or access requests together when possible rather than processing each one separately. Implement asynchronous processing for non-critical decisions so that agents do not block while governance systems evaluate requests. These performance optimizations ensure that governance does not become a bottleneck as your agent fleet scales to thousands or tens of thousands of concurrent operations.&lt;/p&gt;

&lt;p&gt;Caching common decisions eliminates redundant processing. Cache the results of frequently accessed policy evaluations, authorization checks, or permission lookups. When an agent requests access to the same resource multiple times, return the cached result instead of recomputing it. Implement cache invalidation strategies that balance performance with security, such as time-based expiration or event-driven invalidation when policies change.&lt;/p&gt;

&lt;p&gt;Connection pooling and load distribution manage resource utilization efficiently. Implement connection pools for communications between agents and your governance systems to avoid overhead of establishing new connections for every request. Distribute load across multiple governance instances or worker processes to prevent any single component from becoming a bottleneck. Monitor resource utilization and implement auto-scaling based on traffic patterns to handle peak loads without performance degradation.&lt;/p&gt;

&lt;h2&gt;
  
  
  Cost Management Strategies
&lt;/h2&gt;

&lt;p&gt;Usage-based pricing aligns costs with actual consumption. Track detailed metrics about how your agents use governance services and infrastructure resources. Use this data to negotiate pricing models based on actual usage patterns rather than estimates. This approach prevents over-provisioning while ensuring you have capacity when you need it, creating more predictable and efficient cost management.&lt;/p&gt;

&lt;p&gt;Resource allocation optimization reduces waste. Implement quotas and limits at multiple levels, including per agent, per team, and organization-wide. Monitor utilization patterns and right-size resources based on actual needs rather than peak projections. Automated resource reclamation decommissions agents or resources that have been inactive for defined periods, freeing capacity for active workloads and reducing unnecessary costs.&lt;/p&gt;

&lt;p&gt;Multi-cloud or multi-region strategies provide cost optimization opportunities. Different regions or cloud providers may offer significantly different pricing for the same governance services. Implement abstraction layers that allow your governance systems to operate across multiple environments without being locked into a single provider. This flexibility enables you to choose the most cost-effective location or provider for each workload, reducing overall infrastructure costs.&lt;/p&gt;

&lt;h2&gt;
  
  
  Team and Access Control
&lt;/h2&gt;

&lt;p&gt;Self-service governance reduces bottleneck on central teams. Implement portals where team leads can manage agents, policies, and access controls within their scope without requiring approval from central security or governance teams for routine changes. Central teams focus on defining standards, providing tools, and handling exceptions, while day-to-day management stays close to where work happens. This approach scales better because it distributes decision making across organization.&lt;/p&gt;

&lt;p&gt;Delegated approval workflows enable local accountability. Define approval chains where team leads can approve certain types of changes within their authority boundaries. Implement automated routing of requests through appropriate approval chains based on change type, risk level, or resource impact. This delegation reduces bottlenecks on central teams while maintaining appropriate oversight and audit trails for all changes.&lt;/p&gt;

&lt;p&gt;Just-in-time access provisioning reduces standing permissions. Instead of granting agents permanent access to all systems they might ever need, implement time-bound or use-case-scoped access grants. Agents request access when needed, governance systems evaluate the request against policies, and access is granted for the duration required. This approach reduces security surface by minimizing standing permissions while still enabling agents to function effectively.&lt;/p&gt;

&lt;h2&gt;
  
  
  Maturity Model and Roadmap
&lt;/h2&gt;

&lt;p&gt;Start with foundational capabilities and add sophistication over time. Implement basic agent discovery, policy management, and monitoring in your first phase. Add automated enforcement, advanced analytics, and integration with existing systems in phase two. Build toward fully automated policy engines, predictive anomaly detection, and comprehensive incident response in phase three. This incremental approach allows your organization to gain value early while building toward advanced capabilities without attempting to implement everything at once.&lt;/p&gt;

&lt;p&gt;Measure governance maturity to guide investment decisions. Define clear maturity levels from ad-hoc to optimized, with specific criteria and capabilities for each level. Regularly assess your current state against this model to identify gaps and prioritize investments. Communicate maturity progress to executives to demonstrate value and justify continued investment in governance capabilities.&lt;/p&gt;

&lt;p&gt;Build toward standardization while maintaining flexibility for unique needs. As you scale, certain processes benefit from standardization across your organization. Document best practices and create templates for common agent types, policy patterns, and deployment scenarios. At the same time, maintain flexibility for departments or teams with truly unique requirements that justify custom approaches. This balance between standardization and flexibility enables efficiency without constraining innovation.&lt;/p&gt;

&lt;p&gt;The organizations that successfully scale AI governance do not try to implement everything at once. They start with foundational capabilities, learn from early deployments, and gradually build sophistication over time. They balance automation with human oversight, standardization with flexibility, and performance with security. This measured approach enables confident growth from single-agent deployments to enterprise-scale AI fleets without creating bottlenecks, vulnerabilities, or operational chaos.&lt;/p&gt;

</description>
      <category>cybersecurity</category>
      <category>ai</category>
      <category>agents</category>
      <category>startup</category>
    </item>
  </channel>
</rss>
