Enterprise AI Is Forcing Security Beyond Centralized Review

AI adoption is moving faster than the security processes companies built to govern new technology. A centralized security team may once have been able to inspect deployments individually, approve a narrow set of enterprise tools, and revisit those decisions on a predictable schedule. That model becomes harder to sustain when employees are using multiple models, product teams are building agents, engineering teams are connecting new data sources, and vendors are embedding AI across the software stack.

Scott Brammer is Chief Information Security Officer at RegEd, a compliance technology company serving financial institutions, insurers, and brokers that recently crossed $100 million in annual recurring revenue. He previously built security, compliance, privacy, and corporate IT functions as CISO at Symend, after earlier security and risk roles at Travelers and Visa, where his work included embedding security checkpoints into development pipelines. That experience now informs how he approaches AI governance inside a regulated environment.

“If you have proper guardrails and you're already managing agents, MCP servers, and data flows, the model doesn't matter. It should be as pluggable as software is,” Brammer says. His point is that security architecture has to withstand constant model change without forcing teams to rebuild the review process around every new version or provider.

Why security review has to move closer to the builders

The first phase of enterprise generative AI governance was comparatively contained. Security teams could focus on approved subscriptions, access controls, and preventing sensitive information from reaching unmanaged tools. It was a simpler environment than the one most companies are now managing. “We are now in a space where it's much more nuanced,” Brammer says. “We've approached agentic AI. Everybody is using, everybody is delivering, everybody is developing, which means you need a lot more flexibility with your control sets.”

Hybrid environments add more complexity. One team may use one commercial model, another may prefer a different provider, while an engineering group builds something custom around internal data. Agents and MCP servers add another layer of connectivity, and the volume keeps growing even when security headcount doesn’t. “There's going to be more AI tomorrow, and I don't know of any security teams that are getting extra people right now,” Brammer notes.

Security capability has to move closer to the teams building and operating AI. “You're going to need centers of excellence,” Brammer argues, “which means you are going to need a product-enabled team, and an engineering-enabled team that knows how to do guardrails, how to check them, and how to evidence them.”

Risk determines how far controls need to go, while data sources and data sinks show where systems connect and what they can reach. Brammer reduces the baseline to three fundamentals: sandbox the environment, sanitize what enters it, and certify what comes out. “If you have those three basics,” he says, “you can reach for all the rest.” The broader objective is to push those controls earlier into development rather than leave security to inspect finished systems after the fact.

Security controls have to outlast the model

A model upgrade, downgrade, or provider switch is often treated as an event that can invalidate the previous review, but the governance built around restarting the process with every change won’t scale. “We are in month four of the largest Patch Tuesdays in software history,” Brammer says. Companies already manage constant software updates, and he expects model changes to become similarly routine. If development, deployment, agent, MCP, and data controls are designed properly, a version change should be absorbed by that system rather than forcing security back to the beginning.

Model management challenges remain. Different models behave differently, carry different costs, and perform better or worse across specific tasks. Centers of excellence therefore also have to guide users toward the right models and configurations while communicating changes when one option disappears, or another becomes available.

Brammer's own organization is working toward an environment where models can be made as hot-swappable as possible. “If you're doing some no-code solutions, you might need X,” he says. “If you're doing some highly mathematical functions, you might need Y. If you're writing policy or data comments, you might need Z.” The model can change while the surrounding governance remains in place, with observability showing whether the swap is actually working.

Observability as a control layer for distributed AI

Once security execution is distributed across product and engineering teams, visibility becomes the mechanism that keeps that model governable. Security needs to know what systems are running, what they’re touching, and whether the controls around them are working as intended.

For Brammer, those signals should already be part of daily and weekly operating metrics, giving product and engineering teams visibility into usage, cost, configuration, and output quality. “You need to be able to show them: 147 prompts occurred in this product today. These were the weights that were applied. Here were the results. Ninety percent of them were certified as accurate,” Brammer illustrates. “If you don't have that built into the pipelines, into the delivery, and have that telemetry, that's what you need to work on.”

That visibility gives the CISO better evidence for the product and budget decisions that shape AI deployment. Adoption rates, lagging teams, security flaws, and system performance can all move into the same conversation, giving leadership something more concrete than a generalized warning about AI risk.

Observability also exposes the difference between documenting a control and proving that it survives real use. A disclosure page can show what should be happening, while production telemetry shows what’s actually happening once prompts fail, integrations change, or agents behave in unexpected ways. “I want to insist this is our most imperfect science in the security space right now,” Brammer cautions.

Higher exposure requires more rigorous testing

Not every AI system creates the same level of exposure. Brammer contrasts a private, sandboxed AI environment with a client-facing application connected to backend systems, where the consequences of a control failure are much higher.

In a tightly contained model, prompts and weights are controlled and end users have no direct contact with the models. That kind of environment may not justify the same penetration-testing budget as something exposed directly to customers. “As soon as you get into the client-facing chatbot that incorporates data visualizations, has access to backend systems, etc., even if that's controlled agents, controlled MCP servers, or plentiful AI guardrails, that's a space where new skills are required,” Brammer says.

Higher-exposure environments raise the standard for what security needs to know before testing begins. Teams need access to successful and failed prompts, telemetry from agents, and information about the decisions those agents are making. MCP servers require the same level of instrumentation. “If you can't see that information, then you don't know,” Brammer notes.

Testing can then become more continuous. “You can automate daily injections,” Brammer says. “So here's all of the attacks that we're doing against the system today, tomorrow, the following day.” Vendors in continuous assessment and exposure management are already bringing more of this capability into AI security tooling, although Brammer cautions that the market is still developing and not every product performs as advertised.

Inputs and outputs remain the durable security boundary

Security teams can’t control how quickly agents, MCP servers, and models change, but they can control the boundaries around how those systems handle data and interact with infrastructure. For Brammer, that means defining guardrails according to risk, understanding what enters the environment, verifying what comes out, and continuously testing the path between the two.

“AI agents and MCP servers may continue to evolve,” Brammer says. “They may continue to have different versions and versioning. But inputs and outputs, my friend, that's where the game is played.”