Challenges around AI-as-a-Service logging

Challenges Around AI-as-a-Service Logging

Speakers: Jeremy Snyder

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=AccsDqmHPdU

Overview

Jeremy Snyder presented a detailed examination of the current state of logging for AI-as-a-Service offerings, focusing primarily on Amazon Bedrock but touching on broader challenges across cloud providers. As the founder of a company that began life as an API security firm, Snyder brings a practical lens to the problem: organizations are rapidly adopting AI services but have almost no unified visibility into what those services are doing, what data they are processing, or how to detect misuse. The talk catalogues the specific, often maddening inconsistencies in log formats, metadata, and documentation that make building a coherent AI security monitoring capability an exercise in frustration.

Background

▶ Watch: AI spending hits #1 C-suite priority in Q1 2025 (2:00)

The urgency behind AI logging stems from converging trends. AI spending has become the number one priority across C-suite executives as of Q1 2025. Data from the Responsible AI Collaborative shows AI-related security incidents spiking dramatically around the 2021 ChatGPT release. A Capgemini survey of 2,000 enterprise customers found that 97% self-reported experiencing data exposures or breaches related to AI adoption. Organizations are asking whether they are "okay" with their AI usage, but they lack the tools and frameworks to answer that question.

Snyder frames the problem using Fernando Montenegro's taxonomy of workload versus workforce AI consumption. Workload covers LLM-powered applications, agents, and agentic systems built by developers. Workforce covers end-user interactions with AI services through browsers, co-pilots, native apps, and CLI tools. Each category has distinct logging challenges, and neither is well-served by current tooling.

The OWASP LLM Top 10 provides a threat model but not a compliance framework, and when mapped against a logical architecture, most threat areas lack corresponding tool coverage. Real-world incidents are already materializing -- Snyder cited a case documented by Permiso where exposed AWS keys led to an attacker provisioning a jailbreakable Bedrock model, which was then monetized as a sex chatbot on a threat actor's website, with the compromised AWS account footing the bill.

Key Findings

▶ Watch: There is no AI without APIs: workload vs. workforce AI consumption (6:00)

Snyder's research revealed several systemic challenges in AI service logging:

Log format sprawl is pervasive. No cloud provider or AI vendor collaborates on standardized log formats. Amazon Bedrock alone offers 80-100 permutations of model, provider, and version, each potentially producing slightly different log structures. Combined with multi-region deployments, this creates both format sprawl and destination sprawl.

No centralized logging service exists for AI interactions. There is no CloudTrail equivalent for Bedrock. Organizations must route logs through S3 buckets or CloudWatch log groups and use Lambda functions to push them to external destinations. Multiply this by tens or hundreds of AWS accounts and multiple regions, and the operational burden becomes significant.

Log formats are variable and inconsistent. Raw Bedrock logs arrive in JSON but contain inconsistent line breaks, variable stop sequences, and unclear interaction boundaries. A single log file may contain four back-and-forth interactions with no clear delineation between them. The only way to get consistent per-interaction logs is to pause between interactions and wait for the log file to commit.

Bedrock agent logs contain hidden system instructions. When examining agent logs, Snyder's team discovered that substantial predetermined system content -- including instructions like "Never disclose any information about how your memory works" -- was injected by Bedrock without any user input or visibility. This content appeared only in the raw logs.

Cross-region processing is opaque. A request to a model in one region may be processed in another, with limited visibility into where data actually lands. This creates challenges for organizations with data sovereignty requirements.

Guardrails behave inconsistently across models. Amazon's guardrails flagged content as expected. Anthropic's guardrails returned "Unknown." Cohere's model simply ignored the guardrail and processed a Base64-encoded payload that should have been caught.

Client-side logging has fundamental limitations. Browser plugins offer the lowest-hanging fruit for workforce AI monitoring, but response payloads are difficult to capture due to browser DOM security. Endpoint agents typically truncate logs, omitting request payloads and file contents. At best, defenders get user prompts and file names.

AI services pre-process inputs before submission. Snyder's team confirmed that services like ChatGPT begin uploading file contents and pre-processing prompts before the user clicks submit, meaning data exposure begins earlier than most users realize.

Technical Deep Dive

▶ Watch: Color-coded Bedrock agent log reveals hidden system instructions (12:00)

The technical work centered on normalizing disparate AI log formats into a unified structure. Snyder's team attempted to identify a least common denominator across providers, which turned out to be limited metadata like model temperature, P90 latency, and token counts -- even that was inconsistent.

Specific technical challenges included: A21 Labs logs had "super spotty documentation" requiring developers to guess at field meanings. SES log formats varied between V1 and V2 APIs with inconsistencies in casing, pluralization, and field naming (e.g., "API" vs. "APIs", camelCase vs. lowercase). Bedrock agent log parsing required understanding that Lambda functions underpin agent execution, which was only discoverable through log examination.

For workload logging, the architecture requires creating CloudWatch log groups per region and account, then routing them to a centralized destination. For workforce logging, browser plugins emerged as the most practical approach, though they produce fundamentally different data (client-side vs. server-side). Endpoint agent logging through solutions like Zscaler provides URI-level visibility but typically truncates payloads.

Demo / Proof of Concept

▶ Watch: Guardrail inconsistencies: Amazon filters, Anthropic returns Unknown, Cohere ... (16:00)

No formal demo was presented. The talk was structured around screenshots and real log examples from the team's hands-on testing with Bedrock, including color-coded breakdowns of agent log composition showing user input (orange), predetermined system content (blue), and execution metadata (green).

Defensive Implications

▶ Watch: Observations and lessons learned: things will get worse before they get better (20:00)

Organizations beginning their AI security monitoring journey should start by understanding their AI usage landscape across both workload and workforce categories. For workload monitoring, teams need to build per-region, per-account log collection pipelines for Bedrock and similar services, accepting that centralization requires significant engineering effort. Browser plugins offer the fastest path to workforce visibility but should be understood as providing only partial data -- primarily prompts and file names, rarely full responses.

Security teams should examine raw Bedrock agent logs to understand what system-level instructions are being injected into their agents, as this content is not visible through normal administrative interfaces. Organizations with data sovereignty requirements should investigate cross-region processing behavior and validate where their data is actually being processed.

Most importantly, defenders should recognize that AI logging is in a state comparable to early cloud adoption: the providers are prioritizing enablement over security observability, documentation is incomplete and inconsistent, and the landscape is changing week to week. Planning for a stable, long-term monitoring architecture is premature; planning for iterative adaptation is essential.

Key Takeaways

• There is no CloudTrail equivalent for AI service interactions; organizations must build their own centralized logging pipelines from scratch
• AI log formats vary across providers, model versions, regions, and API versions with minimal standardization and poor documentation
• Bedrock agent logs contain hidden system instructions injected by AWS that are invisible through normal interfaces
• AI services pre-process file uploads and prompts before the user clicks submit, beginning data exposure earlier than expected
• Guardrail behavior is inconsistent across model providers, with some models ignoring guardrails entirely
• The AI logging landscape is changing so rapidly (sometimes daily) that building durable monitoring infrastructure requires an iterative, adaptive approach

About the Speaker(s)

Jeremy Snyder is the founder of a company that started three and a half years ago as an API security firm. The company's background in normalizing API logs across different architectures provided the foundation for their investigation into AI service logging. Snyder is primarily experienced with AWS environments and Bedrock, and he acknowledged limited coverage of Azure and Google Cloud AI offerings in this research.