Prompt, Commit, Repeat: Security at Scale When 1,000 Devs Go AI-Native

Prompt, Commit, Repeat: Security at Scale When 1,000 Devs Go AI-Native

Speakers: Balachandra Shanabhag

Conference: BSides SF

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

Overview

In an era where Artificial Intelligence (AI) is rapidly integrating into software development workflows, Balachandra Shanabhag's talk, "Prompt, Commit, Repeat: Security at Scale When 1,000 Devs Go AI-Native," addresses the escalating security challenges faced by enterprises adopting AI coding tools at scale. As developers increasingly leverage AI copilots, agents, and even "wipe coders" that can build and publish applications autonomously, traditional security paradigms are proving insufficient. Shanabhag argues that the sheer variety, rapid evolution, and inherent power of these tools, coupled with their lack of judgment, create a vast and complex attack surface that demands a fundamentally new approach to security.

The core problem articulated is the difficulty of securing an environment where hundreds or thousands of developers are using a myriad of AI-powered coding assistants, often in "YOLO mode" (you only live once), without adequate guardrails. This proliferation introduces novel risks ranging from accidental data deletion and intellectual property (IP) leakage to sophisticated supply chain attacks and the generation of vulnerable code. Shanabhag emphasizes that the non-deterministic nature of AI tools further complicates traditional security controls, making it imperative for organizations to establish robust, multi-layered security frameworks that can adapt to this dynamic landscape.

The talk serves as a critical call to action for security professionals, urging them to proactively define minimum viable security requirements, implement continuous monitoring, and foster a culture of secure AI usage. By dissecting the architecture of AI coding agents, outlining various threat vectors, and proposing a comprehensive lifecycle-based security strategy, Shanabhag provides a pragmatic roadmap for enterprises striving to harness the power of AI development while mitigating its inherent security risks.

Background

▶ Watch: Introduction to the AI Security Challenge (0:00)

The landscape of software development is undergoing a profound transformation with the advent of AI coding tools. What began a few years ago with basic copilots has rapidly evolved into agentic mode coders and even no-developer platforms capable of building and publishing entire applications. These tools manifest in various forms, including self-hosted, open-source, and cloud-based solutions, making their adoption widespread across diverse teams, from marketing for rapid prototyping to engineering for complex development tasks. The speaker notes the rapid pace of innovation, highlighting how new AI models and capabilities, such as the "cheap bot" capable of generating Python code without guardrails, emerge constantly.

This rapid adoption, driven by convenience and efficiency, has outpaced the development of commensurate security measures. Traditional security models, often designed for deterministic systems and human-centric workflows, are ill-equipped to handle the unique characteristics of AI coding tools. Shanabhag vividly illustrates this gap with several real-world incidents:

• An AI agent running in YOLO mode (you only live once) from a user's home directory mistakenly deleted the entire home area, "nuking" the user's Mac. The speaker posits the catastrophic implications of such an incident scaled across a large enterprise with hundreds of users.
• Code execution and code injection vulnerabilities, as seen in tools like Cursor and various VS Code extensions.
• A well-known prompt injection vulnerability in Amazon Q, where the AI agent itself was compromised.
• The Singularity attack, where adversaries leveraged AI tools within breached machines as part of their broader toolchain, demonstrating AI's potential as an attacker's enabler.

These incidents underscore a critical dichotomy: AI coding tools are "200 IQ kids"—extremely smart and powerful, but fundamentally lacking in judgment. They possess the ability to run shell commands, access local files, and read secrets, often operating with the user's full privileges. This inherent power, combined with the ease of jailbreaking or bypassing guardrails, creates an environment ripe for misuse, whether accidental or malicious.

To address this, Shanabhag proposes a threat modeling approach, focusing on a typical AI coding agent as an extreme example of the security challenges. Such an agent typically comprises an LLM (Large Language Model) as its intelligence core, utilizing a reasoning model for decision-making. This LLM can be internal, third-party hosted, or even unsanctioned. The agent interacts with users via prompts, accesses internal documentation (e.g., Jira), fetches data from the web (unless restricted), and integrates with third-party plugins or "skills"—a rapidly expanding attack surface in itself. Crucially, these agents often run on developer laptops or dev machines, granting them broad access to local files, SSH keys, and the ability to execute privileged shell commands. The output of these agents can range from generated code pushed to internal SCM (Source Code Management) systems or PR (Pull Request) changes, to importing new dependencies via package managers (npm, pip), pushing directly to production via CI/CD pipelines, or even controlling cloud resources.

From an adversary perspective, the threats are multi-faceted:

• External attackers can leverage prompt injections embedded in external repositories or comments, or engage in dependency poisoning (e.g., slop squatting, a type of typosquatting used for hallucination in early coding agents).
• Malicious insiders can exploit AI tools to build malware in-house, bypassing traditional network firewalls that detect incoming threats.
• Careless insiders, like the user who nuked their Mac, can inadvertently trigger vulnerabilities through "stupid" or unrestricted usage.
• Compromised AI agents, skills, or plugins can introduce malicious functionality, similar to compromised third-party code repos.
• Data exfiltration risks arise when prompts or generated code are sent to third-party AI providers, potentially exposing sensitive IP or secrets if those providers suffer a breach or lack adequate data retention policies.

These threats translate directly into significant enterprise risks:

• Code compromise: Unreviewed or unapproved AI-generated code can introduce vulnerabilities, leading to reputational damage or product breaches.
• Privilege misuse/Trust abuse: Agents operating with excessive privileges can perform unauthorized actions.
• Data exfiltration: IP, secrets, or customer data can be leaked through prompts or AI-generated outputs.
• Supply chain attacks: The tools themselves, or the dependencies they pull, present a vast attack surface.
• Accountability: Tracing "who did what" becomes challenging with autonomous agents.
• Regulatory fines: Exposure of sensitive data (e.g., government contracts, third-party IP) due to AI tool misuse.
• Autonomous execution: Unauthorized or unintended actions by agents.
• Non-deterministic behavior: AI tools can behave unpredictably, bypassing deterministic security guardrails.
• Tool sprawl: The ease of adoption (e.g., $50 credit card purchases) leads to a proliferation of unsanctioned tools.
• Prompt injection: While a "feature" for developers seeking to override system prompts, it's a major attack surface for security.
• Spending limits: AI agents running in unintended loops can incur thousands of dollars in token usage overnight, akin to leaving an EC2 instance running.

In summary, the confluence of diverse, powerful, and rapidly evolving AI coding tools, coupled with their inherent lack of judgment and the ease of unmonitored adoption, significantly elevates enterprise security risks beyond what traditional controls can manage.

Key Findings

▶ Watch: Real-world Incidents: AI Agents Gone Rogue (4:00)

The talk highlights several critical findings regarding the challenges and necessary adaptations for securing AI coding tools at scale:

1. Proliferation and Lack of Control: The rapid and often unmonitored adoption of diverse AI coding tools (copilots, agents, wipe coders) across enterprises creates a sprawling and difficult-to-manage environment. Developers can easily bypass procurement processes by using personal credit cards, leading to a significant increase in shadow IT and unapproved tools.
2. AI's Power Outpaces Its Judgment: AI coding tools are highly capable ("200 IQ kid") but lack inherent judgment. When operated in "YOLO mode" or with excessive privileges, they can perform destructive actions (e.g., deleting entire home directories) or execute unauthorized commands without human oversight.
3. Expanded Attack Surface: AI tools introduce new and exacerbated attack vectors. Prompt injection becomes a primary concern, where malicious instructions can be embedded in code comments or external repositories. Dependency poisoning takes on new forms like "slop squatting," exploiting AI hallucinations. The agents themselves, along with their third-party plugins and skills, become targets for compromise.
4. Non-Deterministic Nature: Unlike traditional deterministic systems where security guardrails can be reliably enforced, AI tools can exhibit unpredictable behavior. They may bypass rules or generate unexpected outputs, making static security controls insufficient and requiring continuous validation.
5. Elevated Enterprise Risks: The adoption of AI coding tools significantly elevates risks across multiple dimensions:

• Code Quality and Integrity: AI-generated code can introduce vulnerabilities, leading to reputational damage or product breaches if not rigorously reviewed.
• Data Exfiltration: Sensitive IP and secrets can be leaked through prompts or outputs sent to third-party AI services.
• Supply Chain Vulnerabilities: The tools, models, and dependencies they pull in create complex supply chain risks.
• Accountability and Compliance: Tracking actions and ensuring regulatory compliance becomes challenging with autonomous agents.
• Financial Risk: Uncontrolled AI usage can lead to exorbitant cloud spending (e.g., "bankrupting a company" by leaving an agent running overnight).

1. Need for a Holistic Security Lifecycle: Securing AI coding tools requires a multi-layered approach that spans the entire lifecycle of tool adoption—from initial evaluation and installation to operational management and ongoing governance. This includes defining clear security requirements, enforcing controls, monitoring usage, and preparing for incident response.

These findings collectively emphasize that a reactive, traditional security posture is inadequate for the AI-native development environment. A proactive, adaptive, and AI-specific security strategy is essential to manage the elevated risks and harness the benefits of these powerful tools responsibly.

Technical Deep Dive

▶ Watch: The '200 IQ Kid': AI Tools' Power vs. Judgment (5:25)

Securing AI coding tools requires a deep understanding of their architecture, threat vectors, and the lifecycle of their deployment. Shanabhag’s technical deep dive outlines a comprehensive strategy, moving from threat modeling an AI agent to defining minimum viable security requirements and implementing multi-layered controls.

AI Coding Agent Architecture and Threat Modeling

An AI coding agent is typically composed of an LLM (Large Language Model) acting as its intelligence core, combined with a reasoning model for decision-making. This core can be hosted internally, by a third party, or even be an unsanctioned model. The agent's interactions are complex:

• User Input: Developers provide prompts.
• Data Sources: The agent can read from internal documentation (e.g., Jira), internal code repositories, or fetch data from the internet (unless restricted).
• Tooling: It integrates with various third-party plugins or "skills," which represent a rapidly expanding attack surface.
• Execution Environment: Agents typically run on developer laptops or dev machines, operating with the user's privileges. This grants them extensive access to local files, SSH keys, and the ability to execute arbitrary shell commands.
• Outputs: The agent’s output can be pushed to internal SCM systems as proposed code changes, import new dependencies (e.g., via npm or pip), or even interact with CI/CD pipelines to deploy code to production or manage cloud infrastructure.

This architecture creates a fertile ground for various adversaries:

• External Attackers: Can leverage prompt injection (e.g., malicious instructions hidden in external code comments or repositories, as seen in Amazon Q). Dependency poisoning can occur through techniques like "slop squatting," where attackers register package names similar to those an AI might hallucinate.
• Malicious Insiders: Can instruct LLMs (especially less-guarded internal ones or easily jailbroken public models) to generate malware or exploit internal systems, bypassing traditional network-based security controls.
• Careless Insiders: May run agents in "YOLO mode" or with excessive permissions, leading to accidental but destructive actions, such as the infamous incident of an AI agent deleting a user's entire home directory.
• Compromised Agents/Plugins: The agent itself, or any of its third-party plugins, can be compromised, turning the tool into an attacker’s asset (e.g., the Singularity attack using AI tools for further breach exploitation).
• Data Exfiltration: Prompts containing sensitive IP or secrets, or the generated code itself, can be transmitted to third-party AI services, risking exposure if those services are breached or lack robust data retention policies.

Enterprise Risks from AI Coding Tools

These threats translate into significant enterprise risks:

• Code Compromise: AI-generated code, if not properly reviewed, can introduce vulnerabilities, leading to product breaches or reputational damage.
• Privilege Misuse/Trust Abuse: Agents running with elevated privileges can perform unauthorized actions.
• Data Exfiltration: Loss of IP or secrets.
• Supply Chain Attacks: Compromise of AI tools or their dependencies.
• Accountability: Difficulty in tracking actions and attributing responsibility.
• Regulatory Fines: Non-compliance due to data exposure or unauthorized actions.
• Autonomous Execution: Unintended or malicious automated actions.
• Non-Determinism: AI’s unpredictable nature renders traditional, deterministic security controls less effective.
• Tool Sprawl: The ease of adoption leads to a widespread, unmanaged use of AI tools across the enterprise, increasing the attack surface.
• Prompt Injection: While a "feature" for flexible interaction, it's a major vector for malicious input.
• Spending Limits: Autonomous agents can incur massive cloud costs if not properly constrained.

Minimum Viable Security Requirements (MVP)

To mitigate these risks, Shanabhag proposes defining an MVP for security requirements for any AI tool considered for enterprise adoption. This MVP should align with the enterprise's risk appetite and cover several key areas:

• Identity and Access Management (IAM): Tools must integrate with enterprise SSO and support MFA.
• Secret Management: Secrets should be provided to the AI tool based on the scope of the task, with restricted access to the machine.
• Data Residency and Retention: Strict controls to ensure data is not used for training and adheres to zero-data retention policies.
• Visibility and Accountability: Tools must provide hooks for monitoring internal "tool calling" and interactions with other systems. Logs should integrate with existing SIM (Security Information and Event Management) systems for continuous monitoring and forensic capabilities.
• Human Intervention: Critical operations should always allow for human interruption and approval.
• Model Control: Enterprises should be able to configure and pin model versions, specify the country of service, and prevent overnight changes that introduce unpredictable behavior.
• Third-Party Risk Management: Implement allow-listing for plugins and continuous validation of their security posture.
• Untrusted Input Boundaries: Each model and tool behaves differently with prompt injections; continuous validation is required.
• Sandboxing: Risky operations should be run in sandbox mode (e.g., VM, container) to reduce risk.

Multi-Layered Controls Across the Lifecycle

Beyond the MVP, security must be enforced throughout the AI tool's lifecycle:

1. Installation and Deployment Controls:

• Code Access Restrictions: Define what code the AI tool can read, especially for regulatory or legal compliance.
• Model/Endpoint Enforcement: Enforce allowed models and endpoints, ensuring they align with approved security requirements.
• Privilege Enforcement: Continuously monitor and enforce scoped privileges, preventing agents from operating with full machine access.
• Secret File Restrictions: Prevent AI tools from reading sensitive files like SSH keys (~/.ssh/id_rsa), passwords, or other well-defined system secrets without explicit human authorization.
• Code Quality and Review: AI-generated code must go through standard branch protections, human reviews, and security pipelines (SAST/DAST).
• Secure Package Sourcing: Force AI agents to fetch third-party packages from internal proxies rather than directly from the internet to prevent malicious package injection.
• Ecosystem Integration: Integrate with existing IAM/SSO for easy user onboarding/offboarding, send logs to SIM, and monitor high-risk agents through EDR (Endpoint Detection and Response) solutions.

2. Operational Controls:

• Sandboxing for Autonomous Agents: For high-risk, autonomous agents, implement sandboxing (VMs, containers) to isolate their execution.
• Restricted Network Access: Limit agent network access to allow-listed web pages and internal resources, preventing data exfiltration to arbitrary internet destinations.
• Configuration Drift Monitoring: Continuously monitor tool settings to prevent users from bypassing security controls (e.g., changing "dangerous mode" settings).
• Prompt Monitoring: Monitor prompts for sensitive data (secrets, customer info, critical IP) to prevent leakage.
• Developer Training: Educate developers on secure AI usage, best practices, and common pitfalls (e.g., not running agents in home directories).

3. Governance and Incident Response:

• AI-Generated Code as Third-Party: Treat all AI-generated or AI-assisted code as third-party code, applying stricter review and policy enforcement than first-party code.
• Provenance Tracking: Maintain clear provenance, indicating whether code is AI-generated or assisted, and prevent humans from overriding this metadata.
• Bias Output Monitoring: For front-facing applications, monitor AI-generated content for biases and implement correction mechanisms.
• Incident Response Playbooks: Develop specific runbooks for AI-related incidents, such as:
• Jailbreaks: Zero-tolerance policy for attempts to bypass AI guardrails.
• Malware Generation: Monitoring and immediate action for internal malware creation.
• Vulnerable Code in Production: Procedures for detecting and remediating compromised AI-generated code.
• Prompt Leakage: Handling incidents where sensitive data is leaked via prompts.
• Outages: Managing automated pipelines when AI tools are down.
• Patching: A robust process for frequently patching AI tools against new CVEs (e.g., prompt injections, third-party risks).
• Licensing Compliance: Implement package-level OSS license validation to prevent AI from incorporating licensed code into proprietary projects without proper attribution or compliance.
• Version and Support Tracking: Maintain an inventory of AI tool versions and their support timelines, as these change frequently.
• Model Updates: Stay current with model updates, as older models may have weaker guardrails.
• Usage Rate Limits: Enforce spending limits to prevent "human error" or agent loops from incurring excessive token costs.

Practical Example: Claude Managed Settings

Shanabhag provides a concrete example using Claude's managed settings to illustrate how these controls can be implemented. These settings offer an enterprise-level control plane to enforce guardrails:

• Enforce Modes: Disable "YOLO mode" or "dangerous mode" in critical environments.
• Enterprise SSO Enforcement: Prevent users from using personal tokens/logins that lack enterprise-grade security and data retention policies.
• Permission Fatigue Reduction: Configure default behaviors for risky operations (e.g., "don't prompt for approval" for less risky, "ask permission" for riskier ones).
• "Don't Allow" List: Explicitly prohibit commands like rm or reading specific sensitive files (e.g., ~/.ssh/id_rsa, ~/.bash_history, ~/.zsh_history, /etc/shadow, /etc/passwd).
• Proxy Package Imports: Force package imports through internal, allowed proxies.
• Prompt Pattern Matching: Implement deterministic rules to detect and block prompts containing secrets or sensitive IP.
• Audit Logging: Ensure all tool actions are audited and sent to the SIM.
• Third-Party Plugin Control: Configure rules to allow/disallow specific plugins.

The speaker also contrasts intent-based (less deterministic) rule files often found in tools like Cursor with the more deterministic managed settings. He notes an interesting case where an AI tool suggested ways for users to bypass security hooks, highlighting the constant cat-and-mouse game in AI security.

In essence, the technical deep dive underscores that securing AI at scale is not a one-time fix but an ongoing, multi-faceted endeavor requiring a blend of architectural controls, lifecycle management, and continuous vigilance.

Demo / Proof of Concept

▶ Watch: Security Engineering: Threat Modeling AI Coding Agents (6:15)

While Balachandra Shanabhag did not present a live, interactive demo or a full proof-of-concept during the talk, he dedicated a significant portion of the "Technical Deep Dive" to walking through practical examples of how security controls could be implemented using Claude's managed settings. He described these as a "sample of how it looks like" and expressed an intention to build out similar examples for other major AI tools and publish them in the future.

The walkthrough focused on concrete configuration options within Claude that an enterprise could leverage to enforce security policies. This included:

• Disabling "YOLO mode": Enforcing a safer operational mode for AI agents.
• Mandating enterprise SSO: Preventing the use of personal tokens that might bypass corporate security and data retention policies.
• Managing permission prompts: Balancing security and usability by deciding when to "ask permission" for risky operations versus allowing them by default.
• Defining a "paranoia list" of forbidden actions: Explicitly blocking commands like rm or preventing the reading of sensitive files such as SSH keys (~/.ssh/id_rsa), password files (/etc/shadow), or shell history files.
• Enforcing internal package proxies: Redirecting AI agent package imports to trusted internal sources to mitigate supply chain risks.
• Implementing prompt monitoring: Using deterministic pattern matching to detect and prevent secrets or sensitive IP from being included in user prompts.
• Ensuring comprehensive audit logging: Capturing all AI tool actions for visibility and accountability.

This detailed, illustrative walkthrough served as a conceptual "proof of concept," demonstrating the feasibility of implementing robust, enterprise-grade security controls within an AI coding environment, even if a live demonstration was not performed.

Defensive Implications

▶ Watch: Key Components of an AI Coding Agent (6:40)

The proliferation of AI coding tools demands a paradigm shift in defensive strategies. Defenders must move beyond traditional network and endpoint security to address the unique challenges posed by AI's power, non-determinism, and potential for rapid sprawl. The key defensive implications derived from Shanabhag's talk are multi-layered and span the entire lifecycle of AI tool adoption:

1. Establish a Minimum Viable Security (MVS) Baseline: Before any AI coding tool is adopted, define non-negotiable security requirements. This includes robust SSO/MFA integration, scoped access to secrets, strict data residency and retention policies (especially preventing data from being used for AI training), and granular model configuration control (e.g., pinning model versions, specifying geographic serving regions). Anything that doesn't meet this baseline should be rejected or tracked as an exception.

1. Implement Multi-Layered Controls for the AI Lifecycle:

• Pre-Deployment: Enforce strict privilege scoping for AI agents, restrict their ability to read sensitive files (e.g., SSH keys, password files), and mandate internal proxies for all package imports to prevent dependency poisoning.
• Integration: Integrate AI tool logs into existing SIM/SIEM systems for centralized monitoring. Ensure high-risk agents are monitored by EDR solutions, treating them as potential attack vectors or tools used by attackers.
• Runtime Protection: For autonomous or high-risk operations, mandate sandboxing (VMs, containers) to isolate the agent's execution. Implement allow-listed network access policies to prevent unauthorized data exfiltration. Continuously monitor for configuration drift to ensure agents adhere to defined security settings.

1. Proactive Prompt and Output Monitoring: Implement mechanisms to monitor user prompts for sensitive data (secrets, IP, customer information) using deterministic pattern matching. Similarly, monitor AI-generated outputs for potential vulnerabilities, biases, or unintended disclosures. This requires tools with robust hook capabilities to intercept and analyze prompts and outputs.

1. Treat AI-Generated Code as Third-Party Code: This is a critical shift. All code generated or assisted by AI should be subjected to the same rigorous security pipelines, human review processes, and branch protections as untrusted third-party dependencies. Crucially, provenance tracking must be maintained, clearly labeling AI-generated code and preventing developers from overriding this metadata.

1. Focus on Developer Training and Awareness: A significant portion of AI-related incidents stems from human error or a lack of understanding. Comprehensive training on secure AI usage, the dangers of "YOLO mode," prompt injection risks, and best practices for interacting with AI agents is essential. Developers must understand the implications of the power they wield through these tools.

1. Develop AI-Specific Incident Response (IR) Playbooks: Traditional IR playbooks may not cover AI-specific scenarios. Defenders need to prepare for incidents like AI-generated malware, vulnerable code making it to production, prompt data leaks, AI tool outages affecting CI/CD, and managing frequent patching cycles for AI tools. Specific policies for jailbreaking attempts (e.g., zero tolerance) must be established.

1. Address Licensing and Financial Risks: Implement robust package-level OSS license validation to prevent AI from inadvertently introducing non-compliant code. Also, establish and monitor spending limits on AI token usage to prevent accidental financial drain from runaway agents.

By adopting these defensive strategies, organizations can build a more resilient security posture that not only mitigates the inherent risks of AI coding tools but also enables their secure and responsible adoption at scale.

Key Takeaways

• AI coding tools introduce a vast and evolving attack surface: The rapid proliferation and diverse nature of AI copilots and agents, combined with their inherent power and lack of judgment, create new and complex security challenges that traditional controls cannot fully address.
• Enterprises must define and enforce Minimum Viable Security (MVS) requirements: Any AI tool adopted must meet strict baselines for identity management, data residency, secret handling, visibility, and model control, aligning with the organization's risk appetite.
• Multi-layered controls are essential across the entire AI tool lifecycle: From installation and deployment to operational use and governance, security measures must include privilege enforcement, restricted network access, configuration drift monitoring, and robust integration with existing security ecosystems like SIM/SIEM and EDR.
• AI-generated code should be treated as third-party code: Apply the same rigorous security reviews, branch protections, and provenance tracking to AI-assisted code as you would to untrusted external dependencies to mitigate supply chain and vulnerability risks.
• Proactive monitoring of prompts and outputs is critical: Implement technical controls to scan user prompts for sensitive data and monitor AI-generated content for potential leaks, biases, or vulnerabilities, alongside comprehensive audit logging of all AI agent actions.
• Developer training and AI-specific incident response are non-negotiable: Educate developers on secure AI usage best practices and prepare specific incident response playbooks for AI-related scenarios like jailbreaks, malware generation, and data leakage.

About the Speaker(s)

Balachandra Shanabhag is an experienced security engineer with 15 years in the field. For the past three years, he has dedicated himself to the rapidly evolving domain of AI security, considering himself an "AI security student" due to the continuous learning required. He currently works for Cerebras Systems, a company known for its advanced AI compute technology, boasting significantly faster AI inference capabilities. Prior to Cerebras, Shanabhag contributed to securing distributed data stores at Cohesity. He spent over a decade at Juniper Networks, where he was an early security engineer involved in building various network gear, from firewalls to core routers in the telecom space, witnessing the growth of these systems from bootstrap to maturity. Shanabhag is not highly active on social media but is open to connections on LinkedIn for follow-ups and discussions. He emphasizes that any opinions shared during his talks are his own and are not influenced by vendor bias.