A CTO is not expected to review the authorization logic in an agent's tool implementation personally. They are expected to ask questions specific enough that a vague answer becomes visible for what it is. General questions like "is our AI secure" invite general answers like "we're being careful," which reveal nothing about whether the underlying controls actually exist. A short set of specific questions, asked consistently across every team building AI features, does a lot more work.
"What can this feature access that it doesn't strictly need?"
This question targets over-provisioning directly. A confident, specific answer names the exact data sources and describes why each one is needed. A vague answer, "it has access to whatever it needs to be helpful," usually means nobody has actually scoped the access down from whatever was convenient during development. This is worth pushing on, because over-provisioned access is one of the most common and most consequential architecture mistakes in AI features.
"What happens if this feature is fully manipulated by an attacker?"
This question forces a team to think in terms of worst-case impact rather than expected behavior. A useful answer describes a specific, bounded outcome: "the worst it could do is issue a refund up to this limit, which requires approval above that." An answer like "the model is trained to refuse harmful requests" does not actually answer the question, because it describes intended behavior, not the bound on what happens if that intention fails.
"Who can change this feature's prompts or tools without review?"
This question surfaces a governance gap that is easy to overlook. If any engineer can update a system prompt or add a new tool integration and push it to production without a second reviewer, the feature's actual security posture can change at any time without the CTO, or anyone else outside that one engineer, knowing. A specific answer names the review process. A vague answer, "the team is careful about this," is not a process.
"How would we know if this feature started behaving unusually?"
This question checks for monitoring, and a specific answer describes actual signals being tracked: denial rates, unusual tool sequences, cost or latency anomalies, and who is responsible for noticing them. A vague answer, "we'd probably hear about it," usually means detection depends on a customer complaint or a lucky observation rather than anything built to catch a problem early.
"What's the fastest way to turn this off, and who can do it?"
This question checks incident readiness. A specific answer names a mechanism, a feature flag, a kill switch, a specific runbook step, and a specific role authorized to use it without needing further approval during an active incident. A vague answer, or an answer that requires several people to coordinate before anything can be disabled, reveals a gap that matters most exactly when speed matters most.
"What did we test against, and what did we not test?"
This question is useful because most teams can describe what they tested confidently, and the interesting information is in what they admit they did not test. A team that says "we haven't run adversarial prompt injection tests yet" has given a more useful answer than a team that claims comprehensive testing without being able to describe what that testing actually covered.
Why these questions work better than a general audit
A comprehensive technical audit is valuable, but it takes time and specialist review that a CTO cannot personally provide for every feature across a growing number of teams. These six questions are fast to ask, hard to answer convincingly without the underlying work actually being done, and specific enough that a team's response quality tells you a lot about whether the real work happened, even without a CTO independently verifying every technical detail.
Using the answers to prioritize, not to punish
The purpose of asking these questions is to find gaps early and prioritize closing them, not to penalize a team for an honest "we haven't gotten to that yet." A team that answers vaguely because the work genuinely has not been done is giving useful signal. Treating that honesty as a problem discourages teams from giving straight answers next time, which defeats the purpose of asking in the first place.
Where TELEON fits
For the specific questions about access scoping, worst-case impact bounds, and detection of unusual behavior, a runtime policy and audit layer like TELEON, deployed through the gateway or supported middleware, can turn a team's answer from a description of intent into a demonstrable, enforced control with a record to back it up.
The governance question about who can change prompts and tools without review, and the incident-readiness question about who can disable a feature, are organizational decisions that a runtime layer cannot answer on its own.
A short question set for leadership
- What can this feature access that it doesn't strictly need?
- What happens if it is fully manipulated by an attacker?
- Who can change its prompts or tools without review?
- How would we know if it started behaving unusually?
- What's the fastest way to turn it off, and who can do it?
- What did we test, and what haven't we tested yet?
A CTO's leverage in AI security comes from asking specific questions consistently, not from personally reviewing every implementation. The quality of the answers, and how often teams can give a specific one instead of a general reassurance, is a reliable signal for where the real gaps are.