From your description it sounds like you are talking about a key which should not be in the SCM repository, yet needs to be included in the final application. Presumably the application binary is not freely downloadable as such, or else anyway could open it up and get your key, but this is fine if the build result is simply being deployed to some server.
In such a case there is not necessarily any problem in having the key present in the target directory (i.e. Jenkins workspace), or indeed in build artifacts (e.g. lastSuccessfulBuild/artifact/target/myapp.war), so long as these things are not publicly readable. In the case of a CloudBees DEV@cloud Jenkins instance, you can use role-based access control to allow the public to see the changelog for your project, and perhaps the build logs (after vetting them to make sure secrets are not printed), but deny access to the workspace and artifacts.
(As far as artifact read permission is concerned, it seems that this is granted to anyone with overall read permission unless Jenkins is run with -Dhudson.security.ArtifactsPermission=true which is not an option for hosted Jenkins. Probably a plugin needs to be created which enables this permission, and probably also “workspace wipe-out” permission, akin to the existing Extended Read Permission plugin. Workspace browse permission is a standard part of Jenkins at least, which would suffice if you are not archiving artifacts but deploying directly at the end of a successful build.)