Building a Secure Python API with IBM Bob

A generated API endpoint can validate a JSON schema correctly while still allowing one customer to read another customer’s order. Secure implementation requires decisions about identity, authorization, data access, and failure behavior that do not follow automatically from a framework or a successful build. IBM Bob can support that work through project rules, implementation assistance, and review workflows. IBM also documents an actor-critic tutorial in which one configured role produces Python code and another reviews it against stated security requirements. Consider a FastAPI order lookup endpoint that must return only orders owned by the authenticated user. The example in this article is an application design, not a claim that Bob supplies the order service’s authentication infrastructure. The team must define the security contract and verify that the implementation meets it. The actor-critic pattern can expose different questions during generation and review, but two AI roles are not equivalent to independent security assurance. They can share mistaken assumptions or overlook the same business rule. Start with a concrete threat model: an authenticated attacker changes the order identifier, sends malformed input, or tries to infer another customer’s data from error differences. Write the expected denial behavior before implementation, including the response status and audit event. This prevents the generated handler from deciding an access policy implicitly through its error branches. Those scenarios make the security requirements testable and keep the workflow focused on actual behavior. IBM secure-code tutorial.

Open the approved repository in a development environment and establish the existing build and test baseline. Define project security guidance using the documented Bob rule mechanism, such as a reviewed .bob/rules/security.md file, and keep it specific to the application. State that authenticated identity comes from the approved middleware, database calls use parameterized queries through the existing access layer, and order ownership must be checked before data is returned. Include constraints for log redaction, response contents, and dependency changes. Then supply the relevant route, authentication dependency, data model, and test fixtures as focused context. Ask for an implementation plan before generating a patch that changes several layers. If using the tutorial’s paired roles, configure their responsibilities clearly: the implementation role produces a candidate change, while the review role examines the diff and requirements without relying on the implementation’s self-assessment. This setup is a configured workflow, not an automatic proof of compliance with every control in a referenced framework. Choose the project’s supported Python and FastAPI versions rather than asking Bob to select arbitrary current releases. Keep production credentials and real customer records out of the workspace context. Review the active file and command permissions before allowing execution, particularly when the repository includes scripts or instructions from untrusted sources. The goal is a controlled environment where the security decisions are visible and the generated code is straightforward to test. IBM actor-critic setup.

Test the endpoint through the framework’s actual request path so authentication dependencies and error handling participate. Verify that an owner can retrieve an order, another authenticated user cannot, missing credentials are rejected, and invalid identifiers produce the documented response. Check whether the lookup itself is scoped by the authenticated customer or whether ownership is enforced afterward, and confirm that neither path leaks sensitive existence information through responses or logs. Exercise malformed inputs, oversized values, unexpected encodings, and database failures. For parameterized database access, inspect the actual query construction; a test with one obvious injection string is not enough to prove every query path is safe. Run the repository’s configured static analysis, dependency checks, and tests independently of Bob’s review. If a tool reports an issue, determine whether the vulnerable path is reachable and fix the underlying behavior rather than suppressing the finding merely to obtain a clean report. Ask the review role to identify an exploit condition and supporting code location for each significant concern. Validate those claims with a reproducible test or direct inspection. Common mistakes include trusting client-supplied user identifiers, logging full authorization headers, returning internal exception details, and generating tests that mock away the ownership check. A second AI pass can help find these patterns, but the decisive evidence is the final endpoint’s behavior under the stated threat scenarios. Preserve the regression tests so later refactoring cannot silently remove the protection. IBM secure-code workflow.

Production security extends beyond the generated endpoint. Restrict the database account, protect runtime secrets, configure transport security, and apply request-size and traffic controls at the appropriate layers. Decide which security events belong in audit logs and which operational details must remain hidden from clients. Keep dependency versions supported and rerun relevant checks when frameworks, middleware, or authentication libraries change. Treat project rules as maintained guidance rather than an enforcement boundary that replaces tests or permissions. Review deployment configuration separately because a secure handler can still be exposed through an incorrectly configured proxy or an overly privileged runtime identity. Use a controlled release and monitor authorization failures, unexpected response patterns, and database errors without collecting unnecessary personal data. Evaluate Bob’s contribution by measuring defects found before review, rework required, and the quality of the resulting tests and explanations. Do not interpret a clean static-analysis run or an approving critic response as a certification of the service. For the order lookup example, the practical result is an endpoint whose access rule can be demonstrated, whose error behavior is deliberate, and whose maintenance process preserves those properties. Retest access when ownership relationships change, such as moving an order between business accounts. Security depends on current domain relationships as well as the correctness of an individual token. The team remains responsible for verifying that the deployed system protects the intended data. IBM security guidance.